welcome ;-)

ciao tyr_asd, grazie mille per la segnalazione, non conoscevo quella proposta.

l’idea però di basare il tutto sulla correzione di elementi sbagliati non mi convince…per esempio le mancate intersezioni potrebbero essere dovute ad immagini aeree che non permettono di distinguere il punto di giunzione o se esista effettivamente una giunzione o meno…tra l’altro si potrebbe portare a termine il task inserendo un errore (giunzione in un punto sbagliato) e in maniera anche automatica.

a mio avviso è necessario poter confrontare la risposta data dal nuovo utente con una risposta che si sa essere corretta e quindi basare il tutto sul reinserimento di un dato/elemento già presente sul database.

grazie ancora, ciao

Benvenuti e complimenti per le iniziative che state portando avanti. ;-) Aury88

Welcome on board Jat ;-)

an anti-spam/report system is in develop but you can already report an user here: http://wiki.openstreetmap.org/wiki/Spam a moderator will check and eventually remove the reported user.

ottimo! grazie per la segnalazione , lo userò sicuramente ;-)

Great job! but I don’t understand why only motorway_link was narrowed but the other *_links were not I prefer the narrowed behavior.

@escada: I think the way towards 1’o clock at first was the extension of the 6’o clock road (2 line both and the other direction physically separated also both with 2 lanes ) and then, some time later, were added the others roads…and it remain in its initial configuration…I suspect this is also the origin of the straight forward sign on the line to reach it (I would use the straight forward for the upper road and the right sign for the 1’o clock). I pretty sure of the number of lines in that way, but I don’t see how this can be problematic…I thought the main problem was with the difference between turn lanes and intersecting highways (and plus the strange geometry)

my idea is that such a relation could help in many ambiguous situation (number of ways different from the number of turn-lanes and strange intersection/way geometries/orientation) and so can be accepted as a alternative in those cases…

I’m pretty sure it is possible to add a warning if someone touch a relation and, I think, it’s hard that a not-so-expert user would touch a well mapped complex intersection, isn’t it?

about the length problem we can think to use a geometric solution like in the Key:turn (cutting the road based on its number of lines) or is it impossible in the relation scheme?

PS:I re-read my previous comments…I apologize for my really bad English. It is indicative of my state of confusion with the topic xD

@ascada: at the period I saw this I didn’t map the turn lines but today I still don’t know how to map this situation: I encounter a semaphore intersection with three possible left turns (plus one or two straight forward and one for the right turn). in this case only the first line was usable for the first left turn the second for the second and so on…the first line and the second on the left are used to take a (two line ) common way that after 10m the intersection split in two distinct ways so the first line is used for the left-most one and the second for the right-most ( it’s forbidden to use the second line to enter the left-most and vice versa (I suppose for safety reasons). also the third was on slightly left the crossing and the straight forward was slightly right… sadly I don’t remember where it was (it was in china and find it thank to a near wrong element linked by mapproulette) and I didn’t touch it but see it in streetview (so we talk of 2-3 years ago, it’s a year a can’t use streetview and Gmaps )…I hope they put a roundabound junction meanwhile xD the situation was something similar to this sketch but probably there are some errors in the number of lanes on the other ways and definitely it was not oriented like in the sketch…I’m referring only to the lower highway in the sketch

Hi all, this scheme imho is more flexible and (thank to the josm plugin) more noob-proof (like me) than the turn:lanes. I’m not an expert but I ‘ve some consideration about what other users say:

1)Whatever is used significantly more should be the de facto standard. The turn:lanes schema wins here

R:-yap,122 998 ways mapped with turn:lanes is a good number but not so big…in my opinion we can handle this number (today is better than tomorrow ;-) ) our tagging scheme can evolve and deprecate the old one if we gain more details/control over the data.

2)turn:lanes is supported by OsmAnd

R:- Is it possible to use this new scheme while maintain the old one and after a long enough time deprecate the old one? I don’t know how often OSMAnd update their maps but probably we can find a way to coordinate with them in this transition or better let them start support the new scheme and than start map with it…I think this scheme can be very useful for routing engine (mainly in the complex intersection) so for the OSMAnd team probably this can be a tollerable effort

3)problems I see now is that you map the length of a lane as a tag. It should be mapped by splitting the road and tag the number of lanes on each part. There is no need to map the length as an attribute. Mapping the length of something as an attribute is always a bad idea, as the way might be split or merged and nobody will pay attention to adapt those length attributes It is no good idea to use relations for turn lane mapping. Roads are very often touched by newbies. Newbies use iD and/or have no knowledge (iD does not help them to get it) about relations

R:- I don’t like also splitting the road so many time… easily a new and distracted user will join them. with the length tag if a user joins the way’s segments before the intersection or after the tag and the relation is still valid…the problem is when splitting the way before the intersection or when joining way’s segments before and after the intersection but I think those problems remain with the other scheme. Is there a way to add a warning when touching a way in a relation? how is the problem handled in the restriction relations ? Also why a new user would want to touch a (assumed by the presence of the turns description) good mapped intersection?

4) iD isnot of great use adding such kind of relations.

R:- this is the reason to use the iD for some works and other editors for others…I don’t think a newbie will try such a specific and fine mapping neither with the non-relation scheme.

personally I like the new scheme: it’s flexible, it’s very similar to the restriction relation and the plugin seems very easy to use. I really appreciate the “destinations” approach instead of the more generic and ambiguous directions approach

I use path as suggested in the wiki. For the surface I use the surface tag so a footway and a path can be both paved and unpaved. I use path when a way can be described by many highway values but I agree that the distinction between them, ihmo, can be accomplish using the foot/bicycle/motor_vehicle/horse/…tags and some others (sub)tags

the changes seem good ;-)

PS:from zoom level 13 to 16 highway=residential rendering can give some problem in some old, densely urbanised, european town/city: Gela Z13 Gela Z14 Gela Z15 Gela Z16

(oneway=yes should be narrowed but I think this is difficult to obtain without introduce other rendering issues)

However the Humanitarian style work great in this situation. Gela H Z13 Gela H Z14 Gela H Z15 Gela H Z16

I hope you can solve this problem :-)

@ RobJN: About paths/footways “importance” distinction I agree but I think it can be obtained using surface, tracktype, “access” and width tags. so do we really need so many highway (foot, pedestrian, bridleway, path,cycleway)? the main (important for an user ) distinctions between them can be described by already existing tags in my opinion…the only problem can be the legal classification.

Hi guys, in Italy this white yellow orange red scheme doesn’t give any particular problem to me…they are not the colors of the road signs here but I think the important things are to easily recognize the roads from the other elements on the map and discriminate the main roads from the minor ones. This scheme work great with GoogleMaps and I’ve not read or heard of any problem for the UK/Anglophone people using it, so why are there so many problem in OSM?

In carto similar elements have similar colors, the only exception is the actual road color scheme with color that span in an UK centric way (this is not necessary a con) with blue, green, red, orange, yellow, white and grey lines and the first two colors (used for the main roads)are used already to draw other and totally different elements.

So this color-scheme is familiar mainly only with anglophone people and gives serious discrimination problems in the well mapped areas, while the new color-scheme is (sadly)more familiar to anyone using an online map and it has not discrimination problem in well mapped areas.

OSM is an international project, and in some non-anglophone place in the world the actual color scheme has little or no sense. the only way we have to identify the main road is because of their thickness not by their color. with this new color scheme also the color help to discriminate the main roads from the minor one and the same discrimination logic can be used by anyone, including english people.

Ihmo.

Regards

thank you RobJN.

Thank you very much, these tools I will definitely helpful. Aury88

@ yogi_ks I done only the step you wrote (plus a sudo apt-get intall git gifsicle)…but seem it work despite that error ;)

You need also git in the “sudo apt-get install” package list ;)

I think I’ve a problem with make step…this is my make output in terminal:

[ 50%] Building CXX object CMakeFiles/mapolution.dir/cmdline_options.cpp.o [100%] Building CXX object CMakeFiles/mapolution.dir/main.cpp.o Linking CXX executable mapolution [100%] Built target mapolution

Linking CXX executable mapolution is written in red and Building CXX object CMakeFiles/mapolution.dir/cmdline_options.cpp.o reach only 50% but it’s written in green…I don’t know why and if they are ok in this way… I use ubuntu 15.04

In Italy agricultural road are normaly freely accessible (if not private property).They are not so big like in USA but I think have the same purpose. We usually map them with highway=track if they are not generally used by people for normal travels…during the days normally these roads doesn’t see particular traffic except tractors, animals and farmers or fields workers but they can be used by everyone. the classification and the administrator/operator also doesn’t influence the tag…we can have regionals road with a lower level highway value than some provincial roads if they are minor for traffic purpose..it’s rare but can happen. For me there is not problem at all, if you say that those are unclassified roads I’ll map in that way ;)

I’ll try to use also the tracktype tag suggested by lyx.

@ maxerickson: yes, the linked road seem an unclassified road…probably I selected/see the north side where the normal traffic use seemed to me improbable…in this case do you is better to cut the road at the Westview Avenue intersection and tag the south block with unclassified/residential and north with track or do you think it’s better to make it all unclassified?

thank you all guys!

Hi lyx, I’m not expert in the use of the tracktype tag, but it seem to me another tag to use with the tag surface to specify its maintenance grade (it can be applied virtually to any type of surface, asphalt included), but I can not see it from the aerial image… The surface tag seem to me more appropriate for the thing I can see/distinguish from aerials

@Richard/jumbanho So in USA do you use highway=unclassified (+ surface=paved/unpaved/gravel) also for roads with predominant/only agricultural use?

I thought that even in the USA the surface material classification was made through the use of surface tags and the lanes number through the lanes tag; In Europe highway tag is based on the predominant use and traffic intensity not only based on the highway classification so I (wrongly) assumed that this mapping style can also be applied on USA.

Also there are already somehighway=unclassified on the TIGER import in rural areas so I (wrongly again ) assumed that roads were “unclassified” roads and residential ones (in rural areas) were of another kind of roadsand since there were no “track” I wrongly thought those were how TIGER classified track type roads…

So do you think I need to replace highway = truck (+ surface= gravel) with highway = unclassified + surface= gravel for all major agricultural roads (like the one linked in my diary)?

ciao hydrogen2oxygen ho pensato anche io in passato ad una cosa del genere ma non avendo alcuna capacità informatica l’avevo lasciato a livello di concept. teoricamente un metodo come quello suggerito da te è utilizzato da google per trovare gli indirizzi pur non avendoli segnati tutti sul proprio database. Molti mappatori ho visto mappano segnando solo i civici agli incroci oppure usano il tag per l’interpolazione…in questi casi il trovare una posizione con interpolazione pesata alla densità degli edifici potrebbe migliorare di molto l’output del risultato di ricerca dell’indirizzo…purtroppo però non è possibile inserire gli elementi così ottenuti su osm…si introdurrebbero degli errori notevoli e difficili da correggere… fammi sapere come procede lo sviluppo del tuo programma ;)

Hi Pieren, I was thinking the same thing but only for better visualize the buildings in the “third world” countries where the houses’s roofs are usually in metallic material and the rust make them very hard to see in the visible band . So these images could be very usefull also for the HOT project. I don’t know if a mention on the wiki is enought…probably it is better to ask :)