Aury88 has commented on the following diary entries

Post When Comment
inizio about 2 months ago

ciao Franti rise associazione,

anche a nome della comunità italiana ti do il benvenuto su OpenStreetMap (OSM).

Purtroppo non sono della zona ma se hai dubbi o hai bisogno di chiarimenti non esitare a chiedere ;-)

Ne approfitto per segnalarti che, se lo desideri, puoi entrare in contatto con il resto della comunità Italiana tramite mailinglist (ML) dove oltre ad utilissimi suggerimenti per la mappatura sono spesso anche trattati temi più tecnici o news del settore.

Se hai difficoltà come me nella gestione delle ML ti consiglio l'utilizzo di nabble che permette una visualizzazione della ML in stile forum.

Ciao, ancora benvenuto e buona mappatura :-)

Aury88 on Smartphone about 1 year ago

@Piskvor: I found the github page (that was not so easy, we really need a "Report a problem" link xD ) there is already a issues filled by erjiang

Cheers on Smartphone about 1 year ago

@Piskvor: probably, but I fear that is not the right place's probably better to fill a bugreport to the developer page or something like the github page if they exist :-/

i will try mapping about 1 year ago

welcome ;-)

due parole sullo SPAM WAR da Bot e come secondo me potremmo prevenirlo over 1 year ago

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

Siamo principianti ma motivati over 1 year ago

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

Making the switch from Wikimapia to OpenStreetMap over 1 year ago

Welcome on board Jat ;-)

Diary spam? over 1 year ago

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

Controllare le nuove note in una determinata zona di OpenStreetMap over 1 year ago

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

New road style for the Default map style, the full version - high zoom over 1 year ago

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

Mapping turn lanes in OpensStreetMap over 1 year ago

@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

Mapping turn lanes in OpensStreetMap over 1 year ago

@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

Mapping turn lanes in OpensStreetMap over 1 year ago

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 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

New road style for the Default map style - highway=path is evil over 1 year ago

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.

New road style for the Default map style - the first version over 1 year ago

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.



Direct editable tags in osm almost 2 years ago

thank you RobJN.

[2] US County Roads (from residential to track) almost 2 years ago

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

Karnataka 01/2007 to 12/2014: OSM Map Evolution almost 2 years ago

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

Karnataka 01/2007 to 12/2014: OSM Map Evolution almost 2 years ago

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

US County Roads (from residential to track) almost 2 years ago

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'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 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!