Re: [Tagging] Overhead signs (Überkopfwegweiser)
Hi! 2015-01-16 10:19 GMT+01:00 Andreas Labres l...@lab.at: heading Brno: +---+ | Brno,... [A23]| |^^ ^ / | ||| |// | +---+ It might be quite hard for the consumer to determine what arrow/name refers to what lane. 2015-01-19 22:14 GMT+01:00 Johan C osm...@gmail.com: I prefer the existing destination:lanes and turn:lanes tagging, which already provides enough data for a lane assistant (and which is already a bit difficult for novice mappers). http://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details Correct. The consumer may get the names from destination:lanes (and additional information from its sub-tags) and the arrows from turn:lanes. 2015-01-19 22:14 GMT+01:00 Johan C osm...@gmail.com: It might be useful to have a node at the location of the signpost referring to a Mapillary photo. This sounds like a good idea. Maybe we should add a node at the exact position of the signpost and add lane-independent information to that node, like e.g. a photo link, support, colour, maybe dimensions like height. And as some consumers insist on an absolutely realistic representation, we might even add a link to an external vector graphic (e.g. svg). But at least the last one might be a little bit too much at the moment, so let us start with simple photo links. 2015-01-18 18:28 GMT+01:00 fly lowfligh...@googlemail.com: Do we have traffic_sign=destination_sign or highway=destination_sign or similar tag as main tag for the node. Is gauntry that important, that we need an own main tag or would it better fit as subtag ? Eventually even support=* alone will work. As a non-native speaker I obviously prefer traffic_sign=destination_sign, because I never heard of gauntry before. But that's just me. I think traffic_sign=destination_sign + support=gauntry would be a good compromise. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Motorroad does not apply to all lanes
*I looked carefully at the situation of that road bridge in Bremen, and to me it looks clear that the stretch on the bridge cannot legally be a motorroad. When you enter from the west on the on-ramp I bet you do not find any sign telling you that you are entering a motorraod. The motorroad starts again at the next exit, immediately after the bridge where non-motor vehicle have to exit*. It is only for practical reasons that non-motor-vehicles will stay on the right hand lane only. So the correct mapping is that yo remove put motorroad=no on the short stretch on the bridge. This also has the advantage that the average routing algorithm will route your horse-drawn calach correctly over the bridge. Volker On 20 January 2015 at 08:44, Martin Vonwald imagic@gmail.com wrote: Hi! 2015-01-20 3:36 GMT+01:00 715371 osmu715...@gmx.de: motorroad:lanes=yes|yes|yes|no Seems absolutely fine to me. One alternative (for better compatibility) would be motorroad=yes + motorroad:lanes=yes|yes|yes|no . Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Motorroad does not apply to all lanes
2015-01-20 9:06 GMT+01:00 Volker Schmidt vosc...@gmail.com: So the correct mapping is that yo remove put motorroad=no on the short stretch on the bridge. yo remove put - you put ;-) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] sidewalk=* or footway=*
Thanks for the quick response. Sadly the discussion page wasn't much help. But I think I found the right thread on the mailing list (though I haven't read it yet): https://lists.openstreetmap.org/pipermail/tagging/2011-March/007023.html Yours Hubert -Original Message- From: fly [mailto:lowfligh...@googlemail.com] Sent: Dienstag, 20. Januar 2015 01:05 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] sidewalk=* or footway=* Please have a look into the archive of this list and the discussion of the sidewalk proposal. It was designed to replace footway=both/left/right/none but transition is slow. JOSM just introduced a validator warning offering an automatic change. Speaking for myself, I did not care to change a whole city and with your mentioned numbers a well-designed software will still look for both tags. Am 19.01.2015 um 16:44 schrieb Hubert: Hallo, I am working on some ideas for a proposal[1]to double represent cycletracksand footways.It is at the very beginning at the moment and I haven’tmade upmy mindabout how to do that. While I was researchingdifferentstuff, I noticed that the proposals to footway=*[2]and sidewalk=*[3] haven’t been voted on.Yet, it sais“Do not use***footway*=*on other than___highway_http://wiki.openstreetmap.org/wiki/Key:highway=___foo tway_http://wiki.openstreetmap.org/wiki/Tag:highway%3Dfootway”in a warning box ontheKey:footway wiki page [4].It appears that this box has been added by a user only3 days after posting a comment on thediscussionpage. [5] Also aoverpass query[1]as of2015-01-14 has return around 40.000 uses offootway=*on highway=*roads*only, excludinghw=footway/cycleway/path. Howeverthere are500.000 usesof sidewalk=*.While this shows a majority usefor sidewalk=*, I can’t seewhy footway=* should bedeprecatedfor *roads*nor did I find arelated discussion about this. Could someone point meinthe right directionformore information on that topic? Yours Hubert [1]___http://wiki.openstreetmap.org/wiki/User:Hubert87/DoubleRepresent ation_http://wiki.openstreetmap.org/wiki/User:Hubert87/DoubleRepr esentation [2]___http://wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk_ [3]___http://wiki.openstreetmap.org/wiki/Proposed_features/Footway_ [4]___http://wiki.openstreetmap.org/wiki/Key:footway_ [5]___http://wiki.openstreetmap.org/wiki/Talk:Key:footway_ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] sidewalk=* or footway=* (Hubert)
I just found the following Thread ion the GB mailing list: https://lists.openstreetmap.org/pipermail/talk-gb/2012-August/013663.html (I haven’t read it yet.) Is that the one you where referring to? Thank You. Yours Hubert From: SomeoneElse [mailto:li...@atownsend.org.uk] Sent: Dienstag, 20. Januar 2015 00:56 To: tagging@openstreetmap.org Subject: Re: [Tagging] sidewalk=* or footway=* (Hubert) On 19/01/2015 23:19, Warin wrote: To me, sidewalk is American English. British English is more footway? footpath is common Australian English. In English English* footpath means either that thing at the side of the road that Americans call a sidewalk or a path not at the side of the road primarily intended for pedestrians (but less wide than a pedestrianised street). Footway means the same as footpath essentially, but less in common usage and more usually used in legal contexts. The use of sidewalk to describe the thing at the side of the road was discussed on talk-gb and was generally accepted there even by those (like me) who tend not to like Americanisms because it's not ambiguous, whereas the alternatives (footpath and pavement) both are. Cheers, Andy * I can't speak for the Scots or the Welsh or any others. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] sidewalk=* or footway=*
Sorry, was talking about the RFC discussion on this list [6] but your link or better gmane.org [7] as threads are better listed is the starting point. The discussion at the same time about sidewalk as separate ways might be also interesting. cu fly [6] http://thread.gmane.org/gmane.comp.gis.openstreetmap.tagging/7106 [7] http://thread.gmane.org/gmane.comp.gis.openstreetmap.tagging/7051 Am 20.01.2015 um 13:55 schrieb Hubert: Thanks for the quick response. Sadly the discussion page wasn't much help. But I think I found the right thread on the mailing list (though I haven't read it yet): https://lists.openstreetmap.org/pipermail/tagging/2011-March/007023.html -Original Message- From: fly [mailto:lowfligh...@googlemail.com] Sent: Dienstag, 20. Januar 2015 01:05 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] sidewalk=* or footway=* Please have a look into the archive of this list and the discussion of the sidewalk proposal. It was designed to replace footway=both/left/right/none but transition is slow. JOSM just introduced a validator warning offering an automatic change. Speaking for myself, I did not care to change a whole city and with your mentioned numbers a well-designed software will still look for both tags. Am 19.01.2015 um 16:44 schrieb Hubert: Hallo, I am working on some ideas for a proposal[1]to double represent cycletracksand footways.It is at the very beginning at the moment and I haven’tmade upmy mindabout how to do that. While I was researchingdifferentstuff, I noticed that the proposals to footway=*[2]and sidewalk=*[3] haven’t been voted on.Yet, it sais“Do not use***footway*=*on other than___highway_http://wiki.openstreetmap.org/wiki/Key:highway=___foo tway_http://wiki.openstreetmap.org/wiki/Tag:highway%3Dfootway”in a warning box ontheKey:footway wiki page [4].It appears that this box has been added by a user only3 days after posting a comment on thediscussionpage. [5] Also aoverpass query[1]as of2015-01-14 has return around 40.000 uses offootway=*on highway=*roads*only, excludinghw=footway/cycleway/path. Howeverthere are500.000 usesof sidewalk=*.While this shows a majority usefor sidewalk=*, I can’t seewhy footway=* should bedeprecatedfor *roads*nor did I find arelated discussion about this. Could someone point meinthe right directionformore information on that topic? Yours Hubert [1]___http://wiki.openstreetmap.org/wiki/User:Hubert87/DoubleRepresent ation_http://wiki.openstreetmap.org/wiki/User:Hubert87/DoubleRepr esentation [2]___http://wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk_ [3]___http://wiki.openstreetmap.org/wiki/Proposed_features/Footway_ [4]___http://wiki.openstreetmap.org/wiki/Key:footway_ [5]___http://wiki.openstreetmap.org/wiki/Talk:Key:footway_ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] sidewalk=* or footway=* (Hubert)
On 20/01/2015 13:01, Hubert wrote: I just found the following Thread ion the GB mailing list: https://lists.openstreetmap.org/pipermail/talk-gb/2012-August/013663.html (I haven’t read it yet.) Is that the one you where referring to? That's certainly one of them, yes. I have a vague recollection that there might be more, as implied here: https://lists.openstreetmap.org/pipermail/talk-gb/2012-August/013670.html Cheers, Andy ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Motorroad does not apply to all lanes
Am 20.01.2015 um 08:44 schrieb Martin Vonwald imagic@gmail.com: 2015-01-20 3:36 GMT+01:00 715371 osmu715...@gmx.de: motorroad:lanes=yes|yes|yes|no Seems absolutely fine to me. One alternative (for better compatibility) would be motorroad=yes + motorroad:lanes=yes|yes|yes|no . this sounds strange to me, a motor road according to German law (and word) is referring to a road, not to a lane, so there shouldn't be roads with lanes of which some are motor roads and others aren't, it is more probable that the whole motor road gets interrupted by the bridge (to allow crossing by all vehicles) and restarts after it. cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Motorroad does not apply to all lanes
2015-01-20 14:56 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com: Am 20.01.2015 um 08:44 schrieb Martin Vonwald imagic@gmail.com: 2015-01-20 3:36 GMT+01:00 715371 osmu715...@gmx.de: motorroad:lanes=yes|yes|yes|no Seems absolutely fine to me. One alternative (for better compatibility) would be motorroad=yes + motorroad:lanes=yes|yes|yes|no this sounds strange to me, a motor road according to German law (and word) is referring to a road, not to a lane, so there shouldn't be roads with lanes of which some are motor roads and others aren't, it is more probable that the whole motor road gets interrupted by the bridge (to allow crossing by all vehicles) and restarts after it. My response was solely to the tagging itself. If the original observation is wrong, that's a completely different story ;-) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] waterway=wadi problem
The flood prone areas are not designed to let you cross a river Yes. I think that is exactly the important point and a very good description/criterion. flood_prone=yes for things that are _not_ designed to be flooded. And waterway=*, ford=* … for things that _are_ designed/expected to be flooded. Lukas Sommer 2015-01-20 4:09 GMT+00:00 johnw jo...@mac.com: I think using flood_prone on places designed to handle water (like a ford) is incorrect. The sections of a freeway that are closed off during flooding (a lane is closed because storm waters cannot properly drain away, or cuttings under train crossings with flood level markers because the road floods - both are flood prone, but their job isn’t to let you cross a waterway. Fords can be dangerous to cross in storms, but their job is to let you cross in the presence of water. The flood prone areas are not designed to let you cross a river, they just end up being flooded because of inadequate drainage. a ford https://goo.gl/maps/aBWlg flood prone (with a warning sign with lights when it is flooded) https://goo.gl/maps/9aFXV doesn’t seeing a ford automatically mean it’s flood prone? it handles river crossings ^_^ Javbw On Jan 20, 2015, at 8:38 AM, johnw jo...@mac.com wrote: Some part of road have concrete parts that are flood_prone during cyclone. How can we (or not) extend it to roads? access:conditional = no @ flood I'm using flood_prone=yes. With surface=concrete. But I was looking for some method to unify intermittent aspects of rivers and roads that are related when roads are crossing river or vice versa. the ford=* key might be useful. They suggest to also tag depth=0 if it is usually dry year round. I think this is the tag you are looking for, especially since the road section is designed to be submerged (the concrete sections) which means it is a ford (as emergency or very large vehicles, like a bulldozer, could still cross on the road). In San Diego, there are several large roads that are built with fords, as access lost during flood conditions is merely an inconvenience. I think this applies to any roadway *designed* to let you cross a river by going through it, even if it is low/dry most of the time (otherwise, floodwaters would easily destroy the crossing). Also, because of the wadi problem, i will be making up a new “wash” proposal - as it seems wadi is completely generic now. Javbw ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Ethnic shops
like: amenity=hairdresser name=Scalp culture=punk ? Exactly, I provided other examples in my previous message such as culture=country, culture=grunge, culture=shinto. Using several keys ethnicity=* + nationality=* + subculture=* all together would be unambiguous but I think culture=* does a good job of merging all keys. I am not sure ethnicity=* alone can cover all the cases such as your hairdresser ethnicity=punk. I think you know it and choose to discard punk / grunge / country / shinto / goth / kawaii tagging? ;) But even with nationalities it sounds strange, eg. ethnicity=canadian / irish / italian / ... Furthermore I do not have examples at the moment but *maybe* ethnicity is more connoted and may lead to awkward tagging for some groups. but culture=* is already used. 84 uses It seems like the remnants of a old proposal [1]. So it looks to me as a bunch of tagging errors where culture=X should be replaced by amenity=X or tourism=X or any appropriate key=X. Based on the current uses and the fact that culture may have several meanings, ethnicity=* seams to me the best choice As far as I understand culture=* is available as a tagging option, the current use is irrelevant. cuisine=* allows to agglomerate two concepts: food ethnicity + food type. This is outlined [2] and detailed [3] in the wiki. This is why ethnicity=* is not a valid key to - in the unlikely event that we wanted to - replace all the current uses of cuisine=*. And I am trying to find the equivalent of cuisine=* for other types of amenities/shops. I appreciate the fact that 'culture' may have several meanings though. I would still consider key culture=* as my preferred option. Within the context of shops and with the associated values related to nationalities and the like, the meaning of culture=* is rather unmistakable. with values as similar as possible to cuisine=*. Whatever the choice I agree that values should be shared with cuisine=* as much as possible. [1] http://wiki.openstreetmap.org/wiki/Proposed_features/culture [2] http://wiki.openstreetmap.org/wiki/Tag:amenity%3Drestaurant [3] http://wiki.openstreetmap.org/wiki/Key:cuisine ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] waterway=wadi problem
On 21/01/2015 10:03 AM, tagging-requ...@openstreetmap.org wrote: Date: Tue, 20 Jan 2015 14:43:16 + From: Lukas Sommersommer...@gmail.com To: Tag discussion, strategy and related tools tagging@openstreetmap.org Subject: Re: [Tagging] waterway=wadi problem Message-ID: CAFTrL-2fWKpTY-8RNU_0Qa7-gq6=9G3arS2JwOnt=5dqfot...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 The flood prone areas are not designed to let you cross a river Yes. I think that is exactly the important point and a very good description/criterion. flood_prone=yes for things that are_not_ designed to be flooded. No! Flood prone means that they are expected to be flooded from time to time. Nothing about the design. I'd hope that the flood_prone tag would be applied to an area, and best if the frequency is noted e.g. once every 100 years. And waterway=*, ford=* … for things that_are_ designed/expected to be flooded. Again no. A ford may be continuously under water. E.G. a road that goes through a river .. where the river normally flows across the top of the road. Some fords may only have water in floods, others seasonally, and others continuously. Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic philosophy of OSM tagging
Warin 61sundow...@gmail.com wrote: What is the basic philosophy of OSM tagging at the top level? ... Is there an FAQ on this? Or has this never been documented I do not have a FAQ on philosophy, only this and that... A few entries about 'how to create/propose/use' tags: http://wiki.openstreetmap.org/wiki/Proposal_process#Significance http://wiki.openstreetmap.org/wiki/Any_tags_you_like#Syntactic_conventions_for_new_tags http://wiki.openstreetmap.org/wiki/User:Joto/How_to_invent_tags http://wiki.openstreetmap.org/wiki/Duck_tagging New tagging scheme should also be designed so that Tagging good practices make sense. http://wiki.openstreetmap.org/wiki/Good_practice http://wiki.openstreetmap.org/wiki/Tags http://wiki.openstreetmap.org/wiki/Namespace ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
On 19.01.2015 12:10, Richard Z. wrote: ##== Disadvantages of semicolon separated lists == ##* parsing of values is required sure parsing is required. How terribly difficult is it to split a string by ;? It's trivial. Xxzme is one of those mappers who try to design tagging rules which simplify software development, by making assumptions instead of asking those who know. The resulting tagging rules are actually a burden for both mappers and developers alike. People like him would better focus on aspects they are familiar with. OSM is a collaborative project after all. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
Friedrich Volkmann Ad hominem. Wow. You are so low. , by making assumptions instead of asking those who know. This is called data analys. Statistics. Numbers. There nobody to ask if users prefer one method over another. The resulting tagging rules are actually a burden for both mappers and developers alike. Have you ever seen what resulted opening_hours? Do you have at least slight idea how many hours were spent on this library https://github.com/AMDmi3/opening_hours.js? You are not only ignorant but annoying person. There no place for your proganda or your unjustified claims. OSM is a collaborative project after all. And you are egoiste who poison OSM database with garbage data. Unusable by other mappers or developers. 2015-01-21 5:37 GMT+03:00 Friedrich Volkmann b...@volki.at: On 19.01.2015 12:10, Richard Z. wrote: ##== Disadvantages of semicolon separated lists == ##* parsing of values is required sure parsing is required. How terribly difficult is it to split a string by ;? It's trivial. Xxzme is one of those mappers who try to design tagging rules which simplify software development, by making assumptions instead of asking those who know. The resulting tagging rules are actually a burden for both mappers and developers alike. People like him would better focus on aspects they are familiar with. OSM is a collaborative project after all. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
On 21.01.2015 02:51, Никита wrote:
payment=efectivo;visa;mastercard;american␣express
payment=mastercard;visa;efectivo
Now try to find *efectivo *with your regexes.
With a perl regex:
^[^=]+=(.*;)?\s*efectivo\s*(;.*)?$
Usually you only have the value in your variable, so you only need:
^(.*;)?\s*efectivo\s*(;.*)?$
But it's better programming style to split the values into arrays before you
work with them, like (in perl):
$_-{single_vals} = split /;/, $_-{compound_val} for keys @tags;
Then you need no regexp at all for your comparisons.
How to query for payment:efectivo=yes? I definitely need regex here.
You have to be aware of values like 1, true, unknown etc.
--
Friedrich K. Volkmann http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
You don't know regexes and theory behind them. I don't care about your
one-line perl hacks.
You will never teach your ugly hacks to to OSM users. You are insane to
write these things as argument for using ;.
You will always fail when I add more data to database. There always pattern
that will broke your regex. But you are guy with rope.
I just an idiot who knows that literal sting payment:efectivo=yes
requires no
computational power other than index search.
There no regex to write for payment:efectivo=yes at all. JOSM and
overpass will understand this query right now, without any modification.
You have to be aware of values like 1, true, unknown etc.
SO WHAT? How this is relevant to '''; usage in value at all? Have you ever
seen numbers in database? Do you too busy with your regexes? What are you
talking about?
http://taginfo.openstreetmap.org/keys/payment%3Acoins#values
http://taginfo.openstreetmap.org/tags/payment%3Acoins=yes - 26 37395.32%
http://taginfo.openstreetmap.org/tags/payment%3Acoins=no 1 142 4.13%
2015-01-21 6:13 GMT+03:00 Friedrich Volkmann b...@volki.at:
On 21.01.2015 02:51, Никита wrote:
payment=efectivo;visa;mastercard;american␣express
payment=mastercard;visa;efectivo
Now try to find *efectivo *with your regexes.
With a perl regex:
^[^=]+=(.*;)?\s*efectivo\s*(;.*)?$
Usually you only have the value in your variable, so you only need:
^(.*;)?\s*efectivo\s*(;.*)?$
But it's better programming style to split the values into arrays before
you
work with them, like (in perl):
$_-{single_vals} = split /;/, $_-{compound_val} for keys @tags;
Then you need no regexp at all for your comparisons.
How to query for payment:efectivo=yes? I definitely need regex here.
You have to be aware of values like 1, true, unknown etc.
--
Friedrich K. Volkmann http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic philosophy of OSM tagging
On Jan 16, 2015, at 6:22 AM, David Bannon dban...@internode.on.net wrote: On Thu, 2015-01-15 at 18:07 +0100, Michał Brzozowski wrote: Some people in Poland (the ones who never browse community forums) maniacally tag every dirt road as highway=track, even if it should be residential+unpaved Thats is a case of tagging for the renderer I'm afraid. They do that because they want to see the map show the unpaved-ness (sorry) of the road. Clearly wrong but you can understand why they do it. I had a quick comment, especially as I have done exactly that when I first started. I’m going back to correct some of my more glaring errors as I clean up what I had done int he past. The biggest thing to me is that is exactly what the mappers are working for - a more accurate map (the output of the renderer) and it takes a long time to get the idea that we’re tagging for a dataset, not an output for the dataset. “Those people talking about relations and semicolons have to worry about that stuff, I’m just tracing imagery in iD!” I’m guessing is the mindset. And especially where I started mapping, in central Japan which had almost no cleanup done since a data import, bringing any order to the spaghetti of badly aligned and outdated “unclassified roads” that covered everything was better than doing nothing. since there is not many obvious visible uses (to new mappers) for the mapping data beside the output rendered onopenstreetmap.org http://onopenstreetmap.org/, then tagging for the renderer is the only possible verifiable way to check to see what they are doing is (remotely) correct. Train stations were confusing as hell to me, as a couple broken areas made me completely flummoxed as to how to get a “station” to “show up” correctly. I worked for hours trying whatever I could to get the station to show up, assuming I was bad at tagging, and I just needed to find the right way to make it show up properly. Maybe if there were some different overlays that can be put onto the OSM site - “Usage” “surface” etc - it would be easy to see what is tagged for purpose of use (driveway) and surface tagged or untagged (paved , ground, gravel, untagged) - it might make checking existing work (for novices such as myself) much easier, especially since I’m not mapping in JSOM or aware of all these web tools everyone seems to know how to use. As an easy (well, easier) fix - it might be a good idea for iD to show, color coded, what option is chosen for a road - white for paved, grey striped for gravel and friends, and brown for various ground / soil/ mud etc. it might make it easier to tag, and easier to keep noobs like me from tagging everything dirt as a track when they want to convey that it’s not a paved road. and it would show that there is a difference between what you see in -carto and what you see in the renderers. Javbw I have had my say on the topic many times as has many other people. It does, IMHO, highlight one more aspect of this philosophy question. People map and want to see the data they enter used in some way. That seeing is an essential part of the feedback loop. We need to consider that when looking at how people choose (or invent) tags. David ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
E.g.? Well you actually smart person out there. Please query for features that support bitcoins or coins as currency http://overpass-turbo.eu/?w=%22payment:coins%22=%22yes%22%20or%20%22payment:bitcoin%22=%22yes%22 Now try to query for only with bitcoin without litecoin tag: payment:bitcoint=* and payment:litecoin!=* Now try to qurery only for features without regular coins: (payment:bitcoint=* or payment:litecoin=*) and payment:coint!=* If really that dumb to answer questions above using regex, please write an regex to filter email address from plain text. Probably because these are for developers, not for users. Nonsense like any of your words. How taginfo is for developers? http://taginfo.openstreetmap.org/keys/payment%3Acoins#values How wiki page is for developers? http://wiki.openstreetmap.org/w/index.php?title=Key:payment:coinsredirect=no 2015-01-21 9:39 GMT+03:00 Friedrich Volkmann b...@volki.at: On 21.01.2015 03:59, Никита wrote: You don't know regexes and theory behind them. [...] There always pattern that will broke your regex. E.g.? You will never teach your ugly hacks to to OSM users. Probably because these are for developers, not for users. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic philosophy of OSM tagging
On Tue, Jan 20, 2015 at 8:34 PM, johnw jo...@mac.com wrote: As an easy (well, easier) fix - it might be a good idea for iD to show, color coded, what option is chosen for a road - white for paved, grey striped for gravel and friends, and brown for various ground / soil/ mud etc. it might make it easier to tag, and easier to keep noobs like me from tagging everything dirt as a track when they want to convey that it’s not a paved road. +1 -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 19.01.2015 12:37, Markus Lindholm wrote: Treating addresses as attributes might be fast and convenient but that kind of scheme becomes incoherent as there is no one-to-one relationship between addresses and other features. E.g. - There are MULTIPLE POIs that all relate to ONE address - There are MULTIPLE addresses that all relate to ONE building So you would end up with a database where the address information is stored all over the place and no coherent way to process it. Better to have bare address nodes and when necessary use a relation to create an association between the address and other features. We already have zillions of POIs (e.g. shop nodes) with address attributes. If you wanted to keep address information separate, you would need to add just as many address nodes and relations. You would even need to separate all addresses from buildings. So your vision is not only incompatible with the addrN scheme, it is incompatible with how addresses are used in OSM altogether. You apparently wish to implement a relational database concept for address information, but this is just impossible because OSM is not a relational database. All data in OSM directly or indirectly contains geographical information. When you use a relation to connect a shop node (which has geographical coordinates) to an address node (which as geographical coordinates), you have two conflicting sets of geographical coordinates. So if you are looking for normalisation, you need to get rid of the address nodes altogether and set the adress tags on the relation directly. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - addrN:*
On 19.01.2015 12:47, Andrew Shadura wrote: It doesn't actually matter if you agree or not, because it doesn't change the fact that buildings in CZ and SK don't have multiple addresses. I cannot judge this. If this is a fact, addr2 is not needed or even plain wrong for conscription numbers in CZ and SK. The addrN scheme just offers a syntax for alternate addresses. Use it where applicable, and don't use it where it is not applicable. The conscription number example in my version of the proposal is from Austria, where it is applicable. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
On 21.01.2015 03:59, Никита wrote: You don't know regexes and theory behind them. [...] There always pattern that will broke your regex. E.g.? You will never teach your ugly hacks to to OSM users. Probably because these are for developers, not for users. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging road illumination quality
On 20/01/2015 6:55 PM, tagging-requ...@openstreetmap.org wrote: Date: Tue, 20 Jan 2015 08:55:37 +0100 From: Volker Schmidtvosc...@gmail.com To: Tag discussion, strategy and related tools tagging@openstreetmap.org Subject: Re: [Tagging] Tagging road illumination quality Message-ID: calq-or5qskwpumdoxq0hjyrrcegkuzoj_j9teb-jgxiyhx6...@mail.gmail.com Content-Type: text/plain; charset=utf-8 As I said earlier, I am also a hobby photographer. The light levels we are talking about are anyway in a range that old-fashioned hand-held light meters are useless. Went out last night .. light level pointing up to street light was 0.0 lux... so less than 0.1 lux. Meaning I could not measure it this way. I'll think about it. A talk to an expert might be worth while? As I said earlier, I am also a physicist and hate using a scale, expressed in numbers, if I have no way of defining what each level means. Therefore guessing the intensity and then putting in a scale 1 ... 10 (to make it look precise) is out for me. On the other hand as a cyclist I know very well if the illumination of a cyclepath at night is none (no lamps at all) or poor or normal or excellent (or whatever verbal scale you invent). So I will try, at least locally such an approach. And in order not to upset things I will use the lit=yes lit:level=poor|sufficient|good approach Volker Lord Kelvin “When you can measure what you are speaking about, and express it in numbers, you know something about it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind; it may be the beginning of knowledge, but you have scarely, in your thoughts advanced to the stage of science.” The suggested tag lit:poor|sufficient|good is subjective - you will get different answers from different people. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
