Re: [Tagging] Various alt_name values?
Or would it be better – if a consens is difficult – to wait until a general resolution for the problem “one key with more than one value” has come up? Lukas Sommer 2014-11-29 5:03 GMT+00:00 Brian Quinion openstreet...@brian.quinion.co.uk: On 29 Nov 2014 00:26, Lukas Sommer sommer...@gmail.com wrote: Okay. I’ll try a summary: We have the choise between two systems: – semicolon system – alt_name_1 system I added support for alt_name_1 because this kept coming up and people were actively abusing alt_name:1 because it happened to work (the :1 actually ends up interpreted as a language and while this could be fixed the combination of language and array using the same syntax adds a lot of complexity and confusion). ; is just a bad way of doing it without the ability to escape ; and universal editor support (which at this point is probably impossible). It also makes storage much more complex since it breaks key=value pairing. I'd say it was a bad idea and just about anything is better. alt_name[1] that colin suggested is interesting and potentially unambiguous. It also has the advantage of making sense to a coder and not requiring special support in editors for magic escape characters. -- Brian ___ 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] Various alt_name values?
On 29/11/2014, Lukas Sommer sommer...@gmail.com wrote:
Okay. I’ll try a summary:
[...]
Thanks for those insights.
Note that this multiple-values discussion has gone beyond the alt_name
key (which is itself a multiple-value key for the name key, making
'multiple alt_name values' kind of silly), so you should look at other
keys in your analysis.
In this current thread, both solutions have had supporters, but there has
been some more support for the semicolon system.
Dont assume the most vocally-supported option is the more popular one.
It would be interesting to widen your analysis to other keys, but so
far it points at numbered keys being more used in practice.
1.) do a formal voting (I would propose the semicolon system)
I dont think there's any need to obsolete one method or another at
this stage. Like the addr:street vs associatedstreet debate, I dont
see either scheme ever disapearing from osm (just like I doubt that
alt_name will ever disappear in favor of multi-value name).
If you want to continue the discussion, try to fix the semicolon
scheme's technical issues instead (litteral ;, empty fields,
false-positives...). You'll never get any scheme universally accepted
unless it works universally, or at least in more cases than the
alternative.
2.) after that: ask for support for this in Nomination (and maybe other
software on which the HOT people rely) for the voted and accepted solution
AFAIK Notinatim already supports semicolons, {alt,loc,old}_foo, and foo_n.
3.) as mid-term goal: fade out the usage of the not-accepted solution
(maybe later even with a mechanical edit – not sure if this is easy)
No (see previous comment).
4.) as long-term goal: ask software to stop using the not-accepted
solution.
I'd rather have ata-model support as a long-term goal.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
[Tagging] How one should tag different sections of library?
There is a large library with multiple sections (for children, for adults, foreign language books, reading room, movie/music borrowing, newspaper section etc etc). There are separate accounts for separate sections, different opening hours. But it is managed by one institution, everything is in the same building, end it is generally considered as one entity. How one should tag it? (1) amenity=library for both general entity and section (impossible for data consumers to understand that some are subsections) (2) use (1) and use some sort of relation to indicate hierarchy (de facto impossible to use for data consumers) (3) maybe introduce a new tag, something like amenity=library_section or something similar? Maybe library=section, without amenity=library and use amenity=libvrary to mark entire entity? Note: I encountered this on tagging Wojewódzka Biblioteka Publiczna w Krakowie, for now I tagged one section using scheme (1) - see http://www.openstreetmap.org/node/2681723223 Note: http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dlibrary has A building can host multiple libraries. Please document the best way to handle this (with example) if you know a good solution. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] path vs footway
On Mon, Nov 3, 2014 at 5:14 PM, johnw jo...@mac.com wrote: AFIK - footway and path are more toward the width, surface, smoothness, maintenance level, and expected use of the way. a sidewalk often gets tagged as footpath, as would be a concrete walkway in a garden. Paths are usually less maintained, less even, narrower, and lower grade surfaces. footpath doesn’t imply horses=no, it implies cars=no. vehicle=no, actually. Bicycles are typically banned on sidewalks unless otherwise posted in most areas that are party to the Bern Conventions on traffic. to me path implies wheelchair=no. I don't know about that, path's generally the multimodal middle between footway (like a city sidewalk) and cycleway (which often implies foot=no; less commonly foot=yes, rarely foot=designated; I explicitly tag if it's unclear on footway, path, cycleway and motorway beyond the absolutely most broad assumptions; though it's safe to say anything that's a sidewalk mapped as a footway in downtown areas of pretty much anywhere in America is probably suspect if it says bicycle=yes without a source). if they are wide, well maintained, somewhat smooth and hard, and easily passible, then they are footpaths. if it is a track for emergency access vehicles that is usually open for hiking, horses, and bikes, then label it is a track instead, cars=emergency or whatever that exact tag is cars=* isn't a tag. motor_vehicle would be... ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] path vs footway
On Tue, Nov 4, 2014 at 4:17 AM, Richard Mann richard.mann.westoxf...@gmail.com wrote: Interesting interpretation of history. Slightly different version: The path tag was introduced by people who couldn't deal with highway=cycleway being shared with pedestrians, and wanted something less mode-specific than highway=footway and highway=cycleway. This is actually an important distinction, as cycleways generally adhere to the applicable highway standards for lane widths, markings and signage, which are usually absent on smaller and/or more multimodally oriented spaces. Compare a paved MUP looping your neighborhood park (which, odds are, is maybe 2-2.5m wide) compared to a cycleway with markings (which tends to be 2.5-3m wide, *per lane*). Consider it the nonmotorized infrastructure distinction between highway=unclassified and highway=tertiary (or higher, when you start throwing on values greater than one for both lanes:forward and lanes:backward for more than turn:lanes:* or start dealing with divided multilane cycleways). Personally I use highway=footway+bicycle=yes if it's low quality and legal for cycling, and highway=cycleway (which implies foot=yes in the UK) if it's halfway decent for cycling. And highway=path in field and forest. I'd avoid using highway=cycleway if it's not built primarily for a cyclist's benefit, readily identifiable with standard pavement markings and signage. Granted, this means there's some decent chunks of infrastructure that end up highway=path; bicycle=designated; foot=designated that end up as major portions of a cycleway and/or hiking network. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] sub key for cycle ways
On Tue, Nov 4, 2014 at 11:44 AM, Hubert sg.fo...@gmx.de wrote: Mo 03.11.2014 20:18 fly lowfligh...@googlemail.com: Either just let your proposal exist and start using it or simply use the lanes:-tagging like biycle:lanes=yes|yes|designated Can I do that, even if the proposal was rejected? It would leave the problem that no one (Routers, Renderes) would use it and it will probably often be changed either to cw=lane or to cw=shared_lane, depending on the mappers preferences. I would do this, supplementing what I consider the legacy cycleway=* key... ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] path vs footway
Interesting! Those are huge cycle ways! Here in japan, they designate small service roads normally blocked with bollards as cycle ways, as the distances covered between the intersecting roads are very long (1-2km sometimes) and sometimes more direct than the road system - but nothing more a path with a painted line - sometimes only 1m per lane (as it is a converted service road. For as much as Japan loves bikes, they usually don't give a care about making anything remotely purpose built in high traffic areas to avoid accidents - bike lanes are woefully inadequate as well. Javbw On Nov 30, 2014, at 10:43 AM, Paul Johnson ba...@ursamundi.org wrote: On Tue, Nov 4, 2014 at 4:17 AM, Richard Mann richard.mann.westoxf...@gmail.com wrote: Interesting interpretation of history. Slightly different version: The path tag was introduced by people who couldn't deal with highway=cycleway being shared with pedestrians, and wanted something less mode-specific than highway=footway and highway=cycleway. This is actually an important distinction, as cycleways generally adhere to the applicable highway standards for lane widths, markings and signage, which are usually absent on smaller and/or more multimodally oriented spaces. Compare a paved MUP looping your neighborhood park (which, odds are, is maybe 2-2.5m wide) compared to a cycleway with markings (which tends to be 2.5-3m wide, per lane). Consider it the nonmotorized infrastructure distinction between highway=unclassified and highway=tertiary (or higher, when you start throwing on values greater than one for both lanes:forward and lanes:backward for more than turn:lanes:* or start dealing with divided multilane cycleways). Personally I use highway=footway+bicycle=yes if it's low quality and legal for cycling, and highway=cycleway (which implies foot=yes in the UK) if it's halfway decent for cycling. And highway=path in field and forest. I'd avoid using highway=cycleway if it's not built primarily for a cyclist's benefit, readily identifiable with standard pavement markings and signage. Granted, this means there's some decent chunks of infrastructure that end up highway=path; bicycle=designated; foot=designated that end up as major portions of a cycleway and/or hiking network. ___ 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] Landuse vs Vegetation vs Landcover proposed cleanup at wiki
We have highly inconsistent content at wiki (feature pages http://wiki.openstreetmap.org/wiki/Category:Features). Inconsistency is not limited to landuse=wood/natural=forest. Another example is landuse=meadow (Landuse http://wiki.openstreetmap.org/wiki/Landuse, Vegetation http://wiki.openstreetmap.org/wiki/Vegetation, Landcover http://wiki.openstreetmap.org/wiki/Landcover). We should think about how to organize content without collisions or at very least place all problematic categories under same Feature (semi-temporary, until we have better idea). I suggest to use (at least temporary) new, broader group in Features http://wiki.openstreetmap.org/wiki/Category:Features that will contain all *=wood features. So end users can access single group instead of having troubles where natural=forest belongs to. Discussion at wiki is here http://wiki.openstreetmap.org/wiki/Talk:Landuse#Landuse_vs_Vegetation_vs_Landcover_cleanup_.28Category:Features.29. Please spread/translate this info. Personally I suggest to use name environment - yes, it broader than anything (Landuse http://wiki.openstreetmap.org/wiki/Landuse, Vegetation http://wiki.openstreetmap.org/wiki/Vegetation, Landcover http://wiki.openstreetmap.org/wiki/Landcover). It is also not limited to Natural environment http://en.wikipedia.org/wiki/Natural_environment (then we cannot use Landuse/amenity) It is not limited to Physical environment http://en.wikipedia.org/wiki/Ecology#Physical_environments (we have semi/virual features like landuse/amenity because Nobody really cares to define their 1cm borders. But we have 1cm accuracy in OSM. Even people who work with GIS systems/landuse databases do not have that level of accuracy. Nobody want to update borders every season. Objects in the real world change over time, every season. But this is ridiculous.to ask people to update them. Despite fact OSM has pretty decent worldwide coverage, we are not that big to update (almost everything) every season/year. We will simply put problematic content (Landuse http://wiki.openstreetmap.org/wiki/Landuse, Vegetation http://wiki.openstreetmap.org/wiki/Vegetation, Landcover http://wiki.openstreetmap.org/wiki/Landcover, with *=woods and meadows) under same roof called Environment. Despite fact that actually everything around us can be placed in Environment it can answer really simple questions: How to map forest? Should user search forest in Landuse? Vegetation? Landcover? it is always be Environment. Thee problematic features should be dispromoted from Features http://wiki.openstreetmap.org/wiki/Category:Features since they don't provide answers to Where to search for Meadow? Where to search for forest? I'm sorry but I hope my English was good enough to describe problem and suggested solution. Do we want to make these changes or if there better solution? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Landuse vs Vegetation vs Landcover proposed cleanup at wiki
I'm sorry, wrong list. See t...@openstreetmap.org. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
