Re: [Tagging] Feature Proposal - RFC - footway=indoor

BTW, i find it very strange that there is a separte highway=* tag for indoor "flat ways" (i.e. corridors), but not for steps. Any reasons for that? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Was there every a proposal for the disused:key=* / abandoned:key=* lifecycle prefixes?

On Thu, 26 Sep 2019, 18:43 Martin Koppenhoefer, wrote: > an unused building remains a building, hence the building=* tag should be > kept. > All disused physical objects i can imagine remain physical objects. Are you saying that we shouldn't use disused: for physical objects?

Re: [Tagging] Was there every a proposal for the disused:key=* / abandoned:key=* lifecycle prefixes?

On Thu, 26 Sep 2019, 18:30 Andy Townsend, wrote: > On 26/09/2019 17:09, Markus wrote: > > > > Thus, those disused toilets could be tagged: > > > > disused:building=toilets > > > No, it's still a building. Yes, it's still a building (a toilets

Re: [Tagging] Was there every a proposal for the disused:key=* / abandoned:key=* lifecycle prefixes?

On Thu, 26 Sep 2019, 17:50 Paul Allen, wrote: > What is sad is that if renderers produce results that go against mappers' > expectations, > mappers will abuse tags to get the results they want and then the open > data that you > seem to feel is the most important part of the project becomes

Re: [Tagging] Was there every a proposal for the disused:key=* / abandoned:key=* lifecycle prefixes?

tagging, by using another prefix for closed services, e.g. was: or closed:, which are both already in use (approx. 35,000 was: vs. approx. 600 closed:). Using disused: for a closed service doesn't feel right anyway. Thus, those disused toilets could be tagged: disused:building=to

Re: [Tagging] Bus Routes PTv2

On Thu, 26 Sep 2019, 13:58 Michal Fabík, wrote: > [...] JOSM was complaining but it's > working fine when I display the route in OsmAnd or use it in navigation. > IIRC it's just a warning, because it might be an error (e.g. with multipolygon relations).

Re: [Tagging] Bus Routes PTv2

d also twice in the relation of the opposite route direction). Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Key:phone] - Suggesting wiki page changing

andoc.org, according to its homepage, but i've not tried it myself. Regards, Markus > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging meadow orchards

On Thu, 19 Sep 2019 at 16:32, Joseph Eisenberg wrote: > > Usually the main land use should be the one that is most economically > important, and also should take up the most land. Most economically important including or excluding subsidies? In Switzerland, farmers receive subsidies for standard

Re: [Tagging] Feature Proposal - RFC - footway=indoor

combinations with indoor=yes are highway=footway + indoor=yes. Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging meadow orchards

On Wed, 18 Sep 2019 at 20:11, Paul Allen wrote: > > Or landuse=silvopasture. AFAIK, silvopasture describes a forest that is also used for grazing livestock. ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] Tagging meadow orchards

ard=meadow_orchard because they imply a primary usage (meadow or orchard respectively), which i think is impossible to determine. Therefore i prefer landuse=meadow_orchard. Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists

Re: [Tagging] Turn lanes separated by road markings

ncreases or decreases, what is the case quite often (e.g. triangle with chevrons or diagonal bars). But maybe something like dividers:width:start=* dividers:width:end=* could be used if the increase is linear. Regards Markus ___ T

[Tagging] Turn lanes separated by road markings

that routers don't announce too late (i.e. when the lanes can't be changed anymore) which lane one has to take. Or is turn:lanes + change:lanes enough? (And what if there were no turn lane markings?) Thanks in advance for your help Regards Markus

Re: [Tagging] Add amenity=childcare to Map Features?

On Sun, 25 Aug 2019 at 06:39, Joseph Eisenberg wrote: > > Should this tag be added to the wiki page Map Features? Yes, please. Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

On Wed, 21 Aug 2019 at 10:11, marc marc wrote: > > Le 21.08.19 à 09:58, Markus a écrit : > > Otherwise, we need a new relation (maybe type=stop_position?) to > > connect the stop position to the waiting area > > imho that's why stop_area relation exist According to th

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

ition?) to connect the stop position to the waiting area, as the route relations would only include one element (highway=bus_stop). Keeping the PTv2 route relations with platform and stop members just for these rare cases doesn't make sense IMO. Regards Markus

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

On Sun, 4 Aug 2019 at 16:40, Martin Koppenhoefer wrote: > > it is just an excuse to insist on using pt=platform for things that aren’t > platforms and justify it with saying it means waiting area. To quote the PTv2 proposal page: "The platform is the place where passengers are waiting for the

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

would have meant a real platform, there were no PTv2 tag for the waiting area of a stop without platform, which is the normal situation for bus stops at many places. Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

, there are platforms that aren't operated (anymore) and therefore aren't waiting areas, that is public_transport=platform's, anymore. [1]: https://www.mapillary.com/map/im/WzQODhqrCxxBLTYj2YJ-8g [2]: https://www.mapillary.com/map/im/9HJR2HmtsEPsPVDV68

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

e written in the recent discussion on talk-transit, OsmAnd's public transportation routing works very well in Stockholm, where only stops (highway=bus_stop) beside the road are mapped. Regards Markus ___ Tagging mailing list Tagging@openstreetmap.

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

gs) a train station only needs a station and platform elements, while a bus or tram station additionally needs highway=bus_stop or railway=tram_stop elements? Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

hway=bus_stop/railway=tram_stop beside the road/rails ("Stockholm scheme"). Disadvantages: the same that are the advantages of 1. It were nice if we could (finally) agree on one solution to solve the current public transport mess. :) Regards Markus _

Re: [Tagging] Was public_transport=platform intended to > always be combined with highway=bus_stop?

rts from another platform. (For example, in Bern, IC 1 to Geneva always departs from platform 5 and IR 15 to Lucerne always from platform 7.) Thus, i think it makes sense to include the platforms in the route relation here. Regards from the (almost) train paradise :) Markus _

Re: [Tagging] Was public_transport=platform intended to > always be combined with highway=bus_stop?

k it helps to know from which platform it departs. Note that bus stops sometimes can also be displaced or even omitted because of roadworks, breakdowns, delays etc. Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

one stop and at other times there is one highway=bus_stop for two stops. And unnecessarily complex because it not only requires a stop_area, but also a stop_area_group. In contrast, my suggestion would only require stop_area's at stations. Regards Markus __

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

* key and thus can be combined with highway/railway=platform (e.g. public_transport=stop; or, alternatively, a new tag for platforms). However, i haven't got any feedback on that idea, so i don't know whether the community would accept such a change in tagging

Re: [Tagging] wheelchair = hiking

On Tue, 18 Jun 2019, 19:36 Andreas Lattmann, wrote: > >IMO wheelchair=yes means accessible for most basic wheelchairs. > > For the paths that are accessible with normal wheelchairs, I have no > doubt: I would tag them with wheelchair = yes, it is on the paths that need > special wheelchairs

Re: [Tagging] wheelchair = hiking

On Tue, 18 Jun 2019, 18:44 Volker Schmidt, wrote: > highway=path >> wheelchair=designated >> > This would only be correct if this path is mainly or exclusively for > wheelchair users. > I presume thet the majority of hiking routes for wheelchair users do not > exclude other users, they are

Re: [Tagging] wheelchair = hiking

On Tue, 18 Jun 2019, 18:42 Andreas Lattmann, wrote: > would be included in the relations > > I was thinking about this new tag because often particular wheelchairs are > used, for example: [1] [2] > > So if I insert wheelchair = yes what other tag can I use to make it clear > that special

Re: [Tagging] wheelchair = hiking

aths wheelchair=designated. If there are only paths, but no routes, tagging the paths wheelchair=designated should suffice. [1]: https://taginfo.openstreetmap.org/tags/route=wheelchair Regards Markus > ___ Tagging mailing list Tagging@opens

Re: [Tagging] Feature Proposal - RFC - Tag:golf=cartpath

quot;a generic or multi-use path open to non-motorized traffic") because golf carts are motorised vehicles. What about a new highway tag instead (e.g. highway=golf_cart_path)? Regards Markus ___ Tagging mailing list Tagging@open

Re: [Tagging] Feature Proposal - RFC - Tag:golf=cartpath

In my opinion it is very useful to tag golf cart paths additionally to highway=service. However, i think a service=* sub-tag like e.g. service=golf_cart_path (instead of golf=cartpath) would better fit to the current highway tagging scheme. Regards Markus

Re: [Tagging] Feature Proposal - RFC - Tag:golf=cartpath

On Sun, 26 May 2019 at 18:39, Mateusz Konieczny wrote: > > link? Seems to be this one: https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:golf%3Dcartpath Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] Definition of Sport

On Sat, 25 May 2019 at 09:46, Warin <61sundow...@gmail.com> wrote: > > But it is a physical activity, with the result of good health and has > dedicated infrastructure ... and therefore is a a sport under the various > definitions of type C. Yes, but i think sport=* should only be added if a

Re: [Tagging] Definition of Sport

. so can be tagged with > the sport tag... Cycleways are primarily built for locomotion, not for keeping healthy or for enjoyment (although this is a nice side effect). Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Definition of Sport

her frequently used values. :) I agree that a definition doesn't seem to be necessary. By the way, thanks to TagInfo, i've just learned about a new sport: https://taginfo.openstreetmap.org/tags/sport=tambourin I first thought it were a mistake. :) Wishing you all a nice (and maybe sporty) weekend! Reg

Re: [Tagging] Definition of Sport

l activity that people do to keep healthy or for enjoyment Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

tions (e.g. you cannot enter w/o a ticket), adding highway=footway is conflicting. Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

I agree that adding highway=footway to platforms is not only redundant, but (as pointed out by Michael) is bad because platforms often have different access restrictions than highway=footway. iD's validation rule should be removed. Regards Markus

Re: [Tagging] Feature Proposal - Voting - camp_site=camp_pitch

ks (e.g. medicinal herbs, asian plants, succulents). Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "Unambiguous crossings" proposals and related questions

ad markings to separate keys will solve this problem. Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

[Tagging] "Unambiguous crossings" proposals and related questions

/File:Crossroads_with_traffic_islands.png Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Misuse of name tag for route description

ation.nameOrder". There you can state a list of tags that JOSM > should try for the display name. I've recently added 'symbol' there and > now I can finally get rid of all the "Gelber Strich" hiking route names > in the area. Great, thanks for the hint! Regards

Re: [Tagging] Misuse of name tag for route description

tag seems like a better solution. Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Misuse of name tag for route description

;broken" by the > existing setup? It is broken, because it's not clear anymore what are real route names (e.g. "Jubilee Line" or "Via Alpina") and what are descriptions. Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Misuse of name tag for route description

nsportation routes it is not. Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Misuse of name tag for route description

ourses) could be combined however you want. This has the advantage that it's more flexible than a pre-formatted and thus static route description. Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/li

Re: [Tagging] Misuse of name tag for route description

tag is usually used. Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Misuse of name tag for route description

ine from=Aldgate to=Watford or by displaying the description=* tag in case there are different route variants, for example during rush hour, at the weekend or in the evening. Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org http

Re: [Tagging] Misuse of name tag for route description

On Fri, 10 May 2019 at 18:16, Markus wrote: > > On Fri, 10 May 2019 at 13:50, Hufkratzer wrote: > > > > It would probably better to use description=* than from=* and to=* > > because not all routes have a named starting point or destination point, > > like e.g.

Re: [Tagging] Misuse of name tag for route description

usually only display the route number (or route type) and their destination (e.g. "701 Le Prese Stazione", "201 Villeneuve", "IR Chur" or "IC 3 Basel SBB"). Route names (e.g. "Bernina Express", "Metropolitan

Re: [Tagging] Misuse of name tag for route description

at. Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Misuse of name tag for route description

used that way and as soon as the editors display the route's description in the relations list [3], i'll fix my mistakes. [3]: https://josm.openstreetmap.de/wiki/Help/Dialog/RelationList Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https:

[Tagging] Misuse of name tag for route description

ditors would also display from=* and to* (or, instead, description=*) if there is no name=tag, in order that the name=* tag can be kept for routes that really have a name=* (e.g. Via Alpina). (I'm sending this email to the tagging mailing list as it doesn't only concern public transporta

Re: [Tagging] Avoid using place=locality - find more specific tags instead

On Tue, 16 Apr 2019 at 16:26, Joseph Eisenberg wrote: > > > @MarKus: Regarding the tagging of islands or lake groups (clusters), I've > > already begun to use the type=group tag and hope that someone will push > > OSM-Carto to render such relations in the future. > >

Re: [Tagging] Avoid using place=locality - find more specific tags instead

oups: https://wiki.openstreetmap.org/wiki/Proposed_features/Group_Relation Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Camp_site=camp_pitch

On Wed, 10 Apr 2019 at 09:05, Joseph Eisenberg wrote: > > I've restarted the proposal process for camp_site=camp_pitch > > https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch Looks good, thank you! Regards Markus ___

Re: [Tagging] Feature Proposal -- Voting result -- shop=fashion_accessories

sheet icon behind "Status: approved" on the feature page. Does it not show up in your browser? [1]: https://wiki.openstreetmap.org/wiki/Item:Q19528 Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreet

Re: [Tagging] Feature Proposal -- Voting result -- shop=fashion_accessories

Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging shared campuses: landuse=school?

=* values like residential, industrial or commercial. Best regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal -- RFC -- service=irregular

t it is a diversion track; it could also be that no route relations have been mapped yet. Besides, a tag on the rail is more stable (i.e. gets less frequently broken) than a route relation. Best regards Markus ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] Feature Proposal -- RFC -- service=irregular

Hi Stefan, On Mon, 1 Apr 2019 at 20:51, Stefan Keller wrote: > > What about track=service? (key track without 's') That doesn't seem to fit well with the other service=* tags (e.g. service=yard) that are already in use: https://wiki.openstreetmap.org/wiki/Key:service#Railways

Re: [Tagging] Feature Proposal -- RFC -- service=irregular

Hi Martin, On Mon, 1 Apr 2019 at 18:21, Martin Koppenhoefer wrote: > > this should get a different name, many people would call their tram, light > rail or underground service "irregular" (from a subjective point of view: you > wait for a means and it arrives too late). Not sure how to better

[Tagging] Feature Proposal -- RFC -- service=irregular

(on the wiki talk page or on the tagging mailing list) is much appreciated! Best regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal -- Voting -- shop=fashion_accessories

Hello list, I've opened the fashion accessory shop proposal for voting: https://wiki.openstreetmap.org/wiki/Proposed_features/Fashion_accessory_shop Best regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https

Re: [Tagging] Do we still need cycleway=opposite_lane? (Was: Do we still need cycleway=opposite?)

On Tue, 19 Mar 2019 at 09:32, Mateusz Konieczny wrote: > > Mar 19, 2019, 8:29 AM by selfishseaho...@gmail.com: >> >> So why not correcting those 850 (6%) incorrect uses of >> cycleway*=opposite_lane instead of inventing a new tagging system for >> it? I've already corrected a few dozen, here's

Re: [Tagging] Status of oneway=cw oneway=ccw

ignated sounds too official, what about signed_direction=*? In any case i would avoid a key containing the word oneway. Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Do we still need cycleway=opposite_lane? (Was: Do we still need cycleway=opposite?)

On Tue, 19 Mar 2019 at 09:14, Mateusz Konieczny wrote: > >> Mar 19, 2019, 8:52 AM by selfishseaho...@gmail.com: >> >> By the way: aren't all contraflow cycle lanes located on the left side >> in countries with right-hand traffic or on the right side in countries >> with left-hand traffic? If so,

Re: [Tagging] Do we still need cycleway=opposite_lane? (Was: Do we still need cycleway=opposite?)

By the way: aren't all contraflow cycle lanes located on the left side in countries with right-hand traffic or on the right side in countries with left-hand traffic? If so, cycleway*=opposite_lane could simply be replaced by cycleway:*=lane, as the direction of the cycle lane is already implied by

Re: [Tagging] Do we still need cycleway=opposite_lane? (Was: Do we still need cycleway=opposite?)

On Tue, 19 Mar 2019 at 00:30, Warin <61sundow...@gmail.com> wrote: > > On 19/03/19 10:03, Graeme Fitzpatrick wrote: >> >> On Tue, 19 Mar 2019 at 07:47, Markus wrote: >>> >>> Unfortunately, many tags are used wrongly (e.g. name, access tags, >>&

Re: [Tagging] Do we still need cycleway=opposite_lane? (Was: Do we still need cycleway=opposite?)

On Mon, 18 Mar 2019 at 19:54, "Christian Müller" wrote: > > What is the "normal traffic flow" of a two-way road? > > After all, opposite_lane made it to be used in combination > with these as well - despite the fact that [1] documents > combination with oneways exclusively. (And because of that

[Tagging] Do we still need cycleway=opposite_lane? (Was: Do we still need cycleway=opposite?)

but i doubt that it gets better with an additional and cryptic cycleway:left:oneway=-1 tag. Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Do we still need cycleway=opposite?

On Sun, 17 Mar 2019 at 13:38, "Christian Müller" wrote: > > I support discouraging both opposite* values. I suppose you mean all three? > Re-using oneway semantics is easy. oneway is an established > tag with established interpretation - if its meaning is not > reshaped in an obscure way it is

Re: [Tagging] Do we still need cycleway=opposite?

On Sun, 17 Mar 2019 at 12:22, Martin Koppenhoefer wrote: > > cycleway=opposite specifies a track (=distinct bicycle carriageway) whose > position and direction are opposite to the direction you would expect (e.g. > it is left for right traffic jurisdictions), right? No, that's

Re: [Tagging] Do we still need cycleway=opposite?

confused with cycleway=opposite_lane. Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - police=*

On Fri, 15 Mar 2019 at 09:19, Mateusz Konieczny wrote: > >> amenity=police would be reduced to indicate that the tag is used for all >> police facilities > > I am against changing meaning of an established tag (even if it has some > mistaggings). +1 On Fri, 15 Mar 2019 at 17:17, Jan S wrote:

Re: [Tagging] Feature Proposal - RFC - police=*

nstead, people would have to double-tag police stations as amenity=police + police=station in order to comply with both the old and the new scheme. This is why i'm unsure whether it's sensible to introduce a new tag for police stations. Regards

Re: [Tagging] Multipolygon (several outers) forest with different leaf_types: mapping strategy?

titute a new object, but is merely the name of its members as a whole. [1]: https://wiki.openstreetmap.org/wiki/Proposed_features/Group_Relation Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Status of oneway=cw oneway=ccw

nd riders. If pedestrians are also only allowed to walk in one direction, it seems you need to add oneway:foot=yes or foot:backward=no. [1]: https://wiki.openstreetmap.org/wiki/Key:oneway#Interpretation_for_routing Regards Markus ___ Tagging mai

Re: [Tagging] shop=clothes vs shop=fashion

On Sun, 10 Mar 2019 at 18:11, Jean-Marc Liotier wrote: > > But ultimately, I believe that shop=clothe+clothes=luxury would take > that special case back into the fold of a logical tagging scheme... The > fewer special cases the better ! This seems like an even better solution. (Though, we still

[Tagging] Feature Proposal – RFC – shop=fashion_accessories

Hi all, I've created a proposal page for fashion accessory shops (shop=fashion_accessories) as there is currently no official tag for this kind of shops: https://wiki.openstreetmap.org/wiki/Proposed_features/Fashion_accessory_shop Best regards Markus

Re: [Tagging] shop=clothes vs shop=fashion

ms): > http://overpass-turbo.eu/s/GOO I'm aware of this linguistic problem. But instead of abandoning shop=boutique, this problem can be solved if editors correct the French translation ("boutique de mode"?) and if renderers display an appropriate icon (maybe a shirt and a ha

Re: [Tagging] shop=clothes vs shop=fashion

for different accessories shops, such as shops that sell accessories for mobile phones, cars, motorcycles or computers. shop=fashion_accessories is unambiguous but has only been used 10 times so far. Regards Markus ___ Tagging mailing list Tagging

Re: [Tagging] shop=clothes vs shop=fashion

gged shop=convenience. [1]: https://wiki.openstreetmap.org/wiki/Tag:shop%3Dnewsagent [2]: http://lists.openstreetmap.ch/pipermail/talk-ch/2019-March/009904.html (in German) Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC rewritten proposal Via_ferrata_simplified

Not only has highway=via_ferrata already been widely used, but via ferratas also don't correspond to the definition of highway=path, which is "a generic multi-use path open to non-motorised vehicles". Regards Markus ___ Tagging mailing list Ta

[Tagging] Feature Proposal – Voting Results – natural=peninsual & natural=isthmus

%3Disthmus for the feature description pages. Regards and have a nice weekend! Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Sharps / syringe disposal

On Sun, 24 Feb 2019, 01:24 Graeme Fitzpatrick, wrote: > > Bins in public areas (parks, public toilets etc) are intended to have > syringes, with needles attached, disposed of into them. I guess someone > could also put an ampoule in there, but I don't think most people > (hopefully) using these

Re: [Tagging] Sharps / syringe disposal

attached to a > syringe) that is the issue > Do you or someone else happen to know what is allowed to throw into a bin labelled 'syringes'? I would have guessed needles and ampoules, but no other sharp waste such as scalpels. Regards Markus ___ Tagging maili

Re: [Tagging] Sharps / syringe disposal

ones as an attribute of the toilet, perhaps syringes_bin=yes? Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Medicine Disposal

) instead of creating something different for a similar use (i.e. > waste=drugs). I don't think that this is a good idea because (a) waste=* is already used over 32,000 times (b) values in keys are considered problematical by many and (c) i don't see a benefit in such a

Re: [Tagging] start_date variants

licate the relation. For objects inside smaller buildings i think a node would be enough. Regards Markus > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] start_date variants

On Sat, 16 Feb 2019, 23:55 Sergio Manzi Then I guess the correct solution would be to not "stick" the amenity to > the building but to a new relation whose only member will be the building > itself. > + 1 > ___ Tagging mailing list

Re: [Tagging] Waterway length

On Sat, 16 Feb 2019, 20:06 Eugene Podshivalov What is the best way to correct this, so that all other langauge pages got > the correction as well? > I'm not aware of any other way than correcting it on each page. I've just done this and also added a note that this tag lacks verifiability. >

Re: [Tagging] Waterway length

On Sat, 16 Feb 2019, 15:26 Andy Mabbett I would suggest that values entered by human mappers are more likely > to be "error prone"; and that we should be more concerned with > on-the-ground reality than "offical" figures. > I agree. Besides, official figures may not be compatible with OSM's

Re: [Tagging] Waterway length

ce> * (optional) Total > length of river in km > This has been added more than four years ago, see: https://wiki.openstreetmap.org/w/index.php?title=Relation:waterway=1120648 Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] waste=trash for amenity=waste_bin/waste_disposal? [Was: Medicine Disposal]

On Sat, 16 Feb 2019, 16:04 Markus > I agree, but what about ordinary rubbish bins or containers? Do > amenity=waste_bin/waste_disposal without a waste=* tag imply waste=trash or > should that be added too? > Corrigendum: the tag is amenity=waste_basket, not amenity=waste_bin. I

[Tagging] waste=trash for amenity=waste_bin/waste_disposal? [Was: Medicine Disposal]

On Sat, 16 Feb 2019, 14:21 Paul Allen Btw, i wonder why the wiki lists trash as a possible value for waste=*. Is >> trash intended to be only used in combinations, such as >> waste=trash;cigarettes? I've supposed that waste=trash is the default for >> amenity=waste_bin and amenity=waste_disposal

Re: [Tagging] StreetComplete 10 / foot=yes on residential

ged with sidewalk=left/right on lateral carriageways, it seems we need something like sidewalk=parallel_carriageway for the medial carriageways as information for routers. Regards Markus > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Medicine Disposal

ringes. Btw, i wonder why the wiki lists trash as a possible value for waste=*. Is trash intended to be only used in combinations, such as waste=trash;cigarettes? I've supposed that waste=trash is the default for amenity=waste_bin and amenity=waste_disposal and thus doesn't have to be added.

<    1   2   3   4   >