Re: [Tagging] relations & paths

2020-05-14 Thread Martin Koppenhoefer
sent from a phone > On 14. May 2020, at 12:49, Steve Doerr wrote: > > Doesn't that violate > https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element ? it doesn’t. Any elements you like :) The tag defines what is an element, for example a route is something “on top” of a highway

Re: [Tagging] Meaning of "administrative" in boundary=administrative, in your country?

2020-05-14 Thread Martin Koppenhoefer
sent from a phone > On 14. May 2020, at 13:16, Paul Allen wrote: > > It makes it more difficult to the extent that a decision has to be made as to > whether we treat the NHS in the UK as a whole as admin level 1 or NHS Wales > as admin level 1. Or some other hierarchical arrangement. Or not

Re: [Tagging] Meaning of "administrative" in boundary=administrative, in your country?

2020-05-14 Thread Martin Koppenhoefer
sent from a phone > On 14. May 2020, at 04:03, Andrew Harvey wrote: > > That doesn't mean that each area needs to have it's own legal entity and > administrator, nor need to be able to set laws, rules, codes etc. just that > the boundary itself is used for some administrative purposes.

Re: [Tagging] Feature Proposal - RFC - Dog hazard

2020-05-12 Thread Martin Koppenhoefer
sent from a phone > On 13. May 2020, at 00:27, Tod Fitch wrote: > > Checking taginfo it seems hazard=* [1] is in use. Why not go with it? > > [1] https://taginfo.openstreetmap.org/keys/hazard there is also documentation. https://wiki.openstreetmap.org/wiki/Proposed_features/hazard

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

2020-05-12 Thread Martin Koppenhoefer
Am Di., 12. Mai 2020 um 18:02 Uhr schrieb Volker Schmidt : > > Bottom line: more we look into this taxi business more interesting and > confusing it gets. > IMHO it is not very confusing. There are taxis, and there are various other kind of individual and mass transportation and leisure rides

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

2020-05-12 Thread Martin Koppenhoefer
sent from a phone > On 12. May 2020, at 02:37, Jarek Piórkowski wrote: > > In short, is this tag "tagging for the tourist"? Those in the know > will know to check if it's a motorcycle taxi or a car taxi stand. if they expect both to have the same main tag, yes. After a while when they have

Re: [Tagging] relations & paths

2020-05-12 Thread Martin Koppenhoefer
sent from a phone > On 12. May 2020, at 06:24, Kevin Kenny wrote: > > Waymarked Trails associates waymarks only with routes, and assumes > that any waymarked route, from local to international, will have a > route relation describing it. > > Is there a reason that you see route relations for

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

2020-05-11 Thread Martin Koppenhoefer
Am Mo., 11. Mai 2020 um 11:45 Uhr schrieb Mateusz Konieczny via Tagging < tagging@openstreetmap.org>: > May 11, 2020, 10:06 by dieterdre...@gmail.com: > > On 11. May 2020, at 03:18, Jarek Piórkowski wrote: > > > Similarly if you were doing an analysis of surface area devoted to > public parking

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

2020-05-11 Thread Martin Koppenhoefer
Am Mo., 11. Mai 2020 um 02:38 Uhr schrieb Cj Malone : > Currently phone has at least 2 uses. A contact number and an incoming > number for a phone box. We should split these out. If we are left with > totally_new_tag_for_phoneboxes and phone, where > totally_new_tag_for_phoneboxes is defined as

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

2020-05-11 Thread Martin Koppenhoefer
sent from a phone > On 11. May 2020, at 10:04, Marc M. wrote: > > I don't imagine we're going to create several objects to describe > that a taxi waiting area has motorcycles, "normal" cars, vehicles > with a lot of passenger seats and vehicles with a heavy > luggage capacity. > on the ground

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

2020-05-11 Thread Martin Koppenhoefer
sent from a phone > On 11. May 2020, at 03:18, Jarek Piórkowski wrote: > > Similarly if you were doing an analysis of surface area devoted to > public parking then you also need to know to check for > access!=private. this is indeed an unfortunate choice. Tagging a private access parking

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

2020-05-10 Thread Martin Koppenhoefer
sent from a phone > On 10. May 2020, at 23:55, Cj Malone wrote: > > I think we should actively encourage more precise tags like > contact:phone when it's a contact number. why is this “more precise”? What about even “more precise” tags, like contact:phone:business_hours=

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

2020-05-10 Thread Martin Koppenhoefer
sent from a phone > On 10. May 2020, at 17:24, Yves wrote: > > Also, it's not like taxis are a must have for renderers, there will be no > drama if a map shows a taxi station inaccurately for a few months all maps actually ;-) Cheers Martin ___

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

2020-05-10 Thread Martin Koppenhoefer
sent from a phone > On 10. May 2020, at 14:43, Paul Allen wrote: > > Either way, it's going to give the wrong results if renderers don't support > it, the question is which wrong way is preferable: ojeks aren't rendered or > ojeks > are rendered as taxis. ojeks getting rendered as cab

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

2020-05-10 Thread Martin Koppenhoefer
sent from a phone > On 10. May 2020, at 14:24, Paul Allen wrote: > > Technically, either approach to > tagging would work I would question this. It would work if all data consumers would evaluate the subtag, i.e. add support for it and it would mean we would require two tags for taxis:

Re: [Tagging] social_facility:for=family

2020-05-10 Thread Martin Koppenhoefer
sent from a phone > On 10. May 2020, at 11:09, klischka wrote: > > In my opinion there is the value > "family" missing on the Wiki ( > https://wiki.openstreetmap.org/wiki/Key:social_facility:for) I agree in principle. Can you give a definition of “family”? Cheers Martin

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

2020-05-10 Thread Martin Koppenhoefer
sent from a phone > On 10. May 2020, at 01:31, Paul Allen wrote: > > If you use amenity=taxi + vehicle=* you > guarantee that any carto which renders amenity=taxi will render ojek ranks > incorrectly at first, and perhaps incorrectly for all time (if they decide > they're > going to ignore

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

2020-05-09 Thread Martin Koppenhoefer
sent from a phone > On 9. May 2020, at 22:50, Florimond Berthoux > wrote: > > Yeah, that's the point... > > Keep it simple. > You know taxi key ? You know motorcycle key ? Yeah, you can contribute > without checking yet another wiki tag page. > > By the way, this how a taxi moto looks

Re: [Tagging] RFC ele:regional

2020-05-08 Thread Martin Koppenhoefer
Am Fr., 8. Mai 2020 um 17:16 Uhr schrieb Martin Koppenhoefer < dieterdre...@gmail.com>: > I was not aware there weren't any meaningful differences (when comparing > some official height references to the German DHHN92 those in wikipedia.de > with delta information all are wi

Re: [Tagging] RFC ele:regional

2020-05-08 Thread Martin Koppenhoefer
Am Fr., 8. Mai 2020 um 14:35 Uhr schrieb Colin Smale : > As I mentioned before, the national datums of the Netherlands and Belgium > differ by over 2m, which for everything connected to water is very > significant. Waterways often form the border, with bridges that cross the > border. You cannot

Re: [Tagging] RFC ele:regional

2020-05-08 Thread Martin Koppenhoefer
Am Fr., 8. Mai 2020 um 14:26 Uhr schrieb Greg Troxel : > Martin Koppenhoefer writes: > > > Am Fr., 8. Mai 2020 um 03:26 Uhr schrieb Greg Troxel : > > the "definition" for "ele:local" (in German language on the English talk > > page of the tag)

Re: [Tagging] RFC ele:regional

2020-05-08 Thread Martin Koppenhoefer
Am Fr., 8. Mai 2020 um 14:09 Uhr schrieb Greg Troxel : > Martin Koppenhoefer writes: > > > Am Fr., 8. Mai 2020 um 03:22 Uhr schrieb Greg Troxel : > > > >> 3) Look up the data sheet and mark it as ele:datum=NGVD29 or > >> ele:datum=NAVD88 as it turns out

Re: [Tagging] RFC ele:regional

2020-05-08 Thread Martin Koppenhoefer
Am Fr., 8. Mai 2020 um 03:22 Uhr schrieb Greg Troxel : > 3) Look up the data sheet and mark it as ele:datum=NGVD29 or > ele:datum=NAVD88 as it turns out. > IIRR, in another mail, you wrote that the difference between these 2 is less than a meter, can you confirm this, or did I understand

Re: [Tagging] RFC ele:regional

2020-05-08 Thread Martin Koppenhoefer
Am Fr., 8. Mai 2020 um 03:26 Uhr schrieb Greg Troxel : > The notion of "local" has the same problem, and it is also a poor choice > of words in that in surveying, "local", refers to coordinate systems > established for particular projects or surveys that have no lasting > significance. > the

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

2020-05-08 Thread Martin Koppenhoefer
sent from a phone > On 8. May 2020, at 00:43, Paul Norman via Tagging > wrote: > > As a next step, I'd map motorcycle taxis as amenity=motorcycle_taxi. Vote > with your mapping. +1, most people who voted no supposedly never saw a motorcycle taxi in their life... Cheers Martin

Re: [Tagging] Is there any tagging scheme for carillons already?

2020-05-07 Thread Martin Koppenhoefer
sent from a phone > On 7. May 2020, at 16:26, lukas-...@web.de wrote: > > But maybe I will start a proposal with attraction=carillon for tagging > carillons which are operated as an attraction, but then the definition of > that has to be very clear, I think. I am all for tagging carillons,

Re: [Tagging] Is there any tagging scheme for carillons already?

2020-05-06 Thread Martin Koppenhoefer
sent from a phone > On 6. May 2020, at 19:54, Paul Allen wrote: > > I'm not sure we need to tag the carillon. The ones in churches I've > encountered or read about aren't operated as attractions. The bells aren't > visible, the mechanisms aren't visible, the operator isn't visible and

Re: [Tagging] Is there any tagging scheme for carillons already?

2020-05-06 Thread Martin Koppenhoefer
what are the requirements, do you require the sound coming from actual bells, or would a recording of bells playing from loudspeakers qualify as well? Midi-generated sounds? Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] Doorzone bicycle lanes

2020-05-06 Thread Martin Koppenhoefer
sent from a phone > On 6. May 2020, at 13:20, lukas-...@web.de wrote: > > I agree with that, but then note that for "justice" we would need a > foot:doorzone=yes, too, because when a sidewalk is in the parking car's > doorzone (I think most sidewalks next to parking:lane=parallel are), there

Re: [Tagging] Is there any tagging scheme for carillons already?

2020-05-06 Thread Martin Koppenhoefer
sent from a phone > On 6. May 2020, at 13:14, lukas-...@web.de wrote: > > In the wiki I found bell_tower=* (but without a carillon-specific value) and > I think a carillon does not have to be a bell_tower at all, so these are two > different things. I am aware of this instance:

Re: [Tagging] Doorzone bicycle lanes

2020-05-05 Thread Martin Koppenhoefer
sent from a phone > On 5. May 2020, at 04:58, Andrew Harvey wrote: > > The third scenario for dooring is just a regular road with no bicycle > infrastructure, but parked cars can still lead to dooring eg > https://www.mapillary.com/map/im/6YlYnuZPdlziwUsF1m7yWA in this case arguably it’s

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

2020-05-04 Thread Martin Koppenhoefer
sent from a phone > On 4. May 2020, at 23:59, Marc M. wrote: > > for all poi (shop, office, craft, bar, restaurant), does phone > and contact:phone have the same meaning or you have another undocumented > meaning that explain it's not the same ? for me a phone booth is a poi. Are you

Re: [Tagging] RFC ele:regional

2020-05-04 Thread Martin Koppenhoefer
sent from a phone > On 4. May 2020, at 23:20, Joseph Eisenberg wrote: > > Is there a reason to use this new tag ele:regional instead of ele:local=* > which is already mentioned on the Key:ele page? > > "The elevation in a local datum can be tagged as ele:local=*, with elevation > specified

Re: [Tagging] RFC ele:regional

2020-05-04 Thread Martin Koppenhoefer
sent from a phone >> On 4. May 2020, at 18:54, Greg Troxel wrote: > This really feels like solving a non-problem. If you just put what's > on the sign in ele, and don't worry about it, that's ok. If somebody > else actually makes a valid, hard-core measuremnt, and fixes it, even > better.

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

2020-05-04 Thread Martin Koppenhoefer
Am Mo., 4. Mai 2020 um 17:46 Uhr schrieb Sören alias Valor Naram < valin...@gmx.net>: > > because some will feel that A and contact:A are not the same thing > > Well, the specification says that they are the same thing by mentioning > both are used to tag contact information. If they're not the

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

2020-05-04 Thread Martin Koppenhoefer
Am Mo., 4. Mai 2020 um 16:05 Uhr schrieb Sebastian Martin Dicke < sebastianmartindi...@gmx.de>: > The non prefixed tags should be replaced manually to avoid such > problems. When a website is not a contact website then it should be > prefixed with another suitable namespace. It would be more

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

2020-05-04 Thread Martin Koppenhoefer
Am Mo., 4. Mai 2020 um 15:16 Uhr schrieb Richard Fairhurst < rich...@systemed.net>: > As someone with admin access over this mailing list, I request that you do > not keep bringing back proposals which were extensively debated beforehand > and generally rejected. It wastes everyone's time. >

Re: [Tagging] RFC ele:regional

2020-05-04 Thread Martin Koppenhoefer
Am Mo., 4. Mai 2020 um 13:10 Uhr schrieb Simon Poole : > The previous versions of the page in particular the one that was actually > voted on (in 2007) does -not- have that reference, see also > https://wiki.openstreetmap.org/wiki/Talk:Key:ele for discussion on the > issue back to 2007. > yes,

Re: [Tagging] 'amenity:hospital' at university hospitals?

2020-05-04 Thread Martin Koppenhoefer
Am Mo., 4. Mai 2020 um 11:50 Uhr schrieb Lena Essig : > Hello, > during mapping hospitals I found some university hospitals which are > inside a university terrain. They are tagged with "buidling:hospital" - > without an amenity tag, and some which are tagged with "building:hospital" > AND

Re: [Tagging] leisure=common

2020-05-04 Thread Martin Koppenhoefer
sent from a phone > On 4. May 2020, at 10:27, severin.menard via Tagging > wrote: > > With this approach we would need to create a lot of new tags, eg for > highways. Primary, secondary and tertiary are hierarchy based and does not > mean the same reality everywhere they do mean the same: a

Re: [Tagging] RFC ele:regional

2020-05-04 Thread Martin Koppenhoefer
Am Mo., 4. Mai 2020 um 10:50 Uhr schrieb Simon Poole : > Historically the understanding was that ele would use "height above the > ellipsoid", there is some reasoning on the Altitude page, might have > made sense originally. In 2013 the ele entry was fiddled to point to the > height above geoid.

Re: [Tagging] RFC ele:regional

2020-05-03 Thread Martin Koppenhoefer
sent from a phone > On 3. May 2020, at 15:23, Jarek Piórkowski wrote: > > What happens when the sign is replaced or removed? if the information on the sign is replaced you should obviously update the value, when it disappears I would not act, but I imagine the purist answer would be to

Re: [Tagging] Doorzone bicycle lanes

2020-05-03 Thread Martin Koppenhoefer
sent from a phone > On 3. May 2020, at 10:52, Andrew Harvey wrote: > > I still would learn towards cycleway:lane:doorzone=yes as being my preferred > option though, since you can tag =no as well. do you really need the lane component? Could be cycleway:doorzone=yes/no or with left/right

Re: [Tagging] RFC ele:regional

2020-05-03 Thread Martin Koppenhoefer
sent from a phone >> On 3. May 2020, at 12:51, Andrew Harvey wrote: > There is an EPSG code https://spatialreference.org/ref/epsg/5711/ for the > datum, perhaps ele:epsg:5711= is better then. A system like this would probably be ignored by 85-98% of our mappers, although I would encourage

Re: [Tagging] RFC ele:regional

2020-05-03 Thread Martin Koppenhoefer
sent from a phone > On 3. May 2020, at 13:06, Volker Schmidt wrote: > > When I see an elevation value on the ground I do not see any reference to the > reference system, so I cannot know, as a mapper, what reference system is at > the base of the informaton that I find on the ground. In

[Tagging] RFC ele:regional

2020-05-03 Thread Martin Koppenhoefer
I’m asking for comments on https://wiki.openstreetmap.org/wiki/Proposed_features/ele:regional Cheers Martin sent from a phone___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Doorzone bicycle lanes

2020-05-03 Thread Martin Koppenhoefer
sent from a phone > On 3. May 2020, at 08:39, Andrew Harvey wrote: > > For a while myself and others have been using cycleway:lane=doorzone to say > the bicycle lane is in a doorzone, I am not completely sure, if I get this right, do you mean the area where a door that is opened, would

Re: [Tagging] Running but no hiking/walking

2020-05-02 Thread Martin Koppenhoefer
sent from a phone > On 2. May 2020, at 17:15, Kovoschiz wrote: > > Eg "walking speed" is often > used as a descriptor, and in this case we have "running". walking speed is still a prescription for vehicles only, it does not exclude pedestrians from running. Cheers Martin

Re: [Tagging] Running but no hiking/walking

2020-05-01 Thread Martin Koppenhoefer
sent from a phone > On 2. May 2020, at 00:37, Jmapb wrote: > > minspeed:foot? A value of around 6 or 7 (default unit is km/hour) should > separate the fast walkers from the joggers. Of course it's anyone's > guess if there would ever be any software support for this key. minspeed and

Re: [Tagging] With leisure=common deprecated, Senegal & Mali need a replacement

2020-04-30 Thread Martin Koppenhoefer
Am Do., 30. Apr. 2020 um 14:07 Uhr schrieb Andy Townsend : > On 30/04/2020 12:10, Peter Elderson wrote: > > landuse=common makes most sense to me. > > name, surface, access etc could be added when applicable. > > > That's currently one of the keys used at >

Re: [Tagging] With leisure=common deprecated, Senegal & Mali need a replacement

2020-04-30 Thread Martin Koppenhoefer
Am Do., 30. Apr. 2020 um 11:59 Uhr schrieb Warin <61sundow...@gmail.com>: > On 30/4/20 7:29 pm, Martin Koppenhoefer wrote: > > > > Am Do., 30. Apr. 2020 um 11:18 Uhr schrieb Jean-Marc Liotier < > j...@liotier.org>: > >> The concept they are closest to is &q

Re: [Tagging] With leisure=common deprecated, Senegal & Mali need a replacement

2020-04-30 Thread Martin Koppenhoefer
Am Do., 30. Apr. 2020 um 11:18 Uhr schrieb Jean-Marc Liotier : > The concept they are closest to is "plaza" > (https://en.wikipedia.org/wiki/Plaza) - which, by the way, does not seem > to have currency in Openstreetmap. place=square Cheers Martin ___

Re: [Tagging] Feature Proposal - RFC - Deprecate healthcare=pharmacy

2020-04-28 Thread Martin Koppenhoefer
while I also don’t see an urgent need to deprecate healthcare=pharmacy, I neither see a compelling reason to use it for “normal pharmacies” (those that are tagged as amenity=pharmacy with dispensing=yes/no). As long as there isn’t a “fix” to remove the amenity tag, the double tagging is not

Re: [Tagging] Points vs Polygons

2020-04-24 Thread Martin Koppenhoefer
Am Do., 23. Apr. 2020 um 17:14 Uhr schrieb Paul Allen : > I do not see why you would have to remove the address information from the >> building when you add it to another object with the same address (like a >> shop). >> > > DRY. Having the same address info for the building and the business >

Re: [Tagging] Points vs Polygons

2020-04-23 Thread Martin Koppenhoefer
Am Mi., 22. Apr. 2020 um 14:12 Uhr schrieb Paul Allen : > This is all true. And in an ideal world we'd map the building and its > occupying > object as two separate-but-coincident objects. This isn't an ideal > world. :( > > Problem 2: Duplication of address info. The building has an

Re: [Tagging] Points vs Polygons

2020-04-22 Thread Martin Koppenhoefer
sent from a phone > On 22. Apr 2020, at 07:51, John Willis via Tagging > wrote: > > -1 I really like tagging info onto landuses and buildings because that is > *exactly* what I’m trying to convey - everything in this area or building is > *this thing* but the building is also a thing,

Re: [Tagging] Refining heritage tag

2020-04-21 Thread Martin Koppenhoefer
sent from a phone > On 21. Apr 2020, at 22:12, António Madeira wrote: > > If you have millions of tags like ref:"whatever", how are you going to > distinguish between them if you make a query or some kind of data reading? by looking at the combination: you query for heritage AND ref tags

Re: [Tagging] Tagging and rendering places without a name

2020-04-21 Thread Martin Koppenhoefer
Am Di., 21. Apr. 2020 um 06:03 Uhr schrieb Warin <61sundow...@gmail.com>: > So by the definition I see no issue of having place without a name tag, as > long as it has a name :) > > Errr If it has a name, tag it. If you don't know its name then how do you > know it is a place? > for example

Re: [Tagging] Too many different features lumped together under amenity=social_facility?

2020-04-20 Thread Martin Koppenhoefer
sent from a phone > On 20. Apr 2020, at 20:02, Paul Allen wrote: > > No it isn't. I'm entirely serious. Amenity has come to mean miscellaneous. > This is not a good thing. this sounds as if you were implying it was different some time ago? Anyway, it is offtopic in this discussion

Re: [Tagging] Feature Proposal - RFC - Tag:path=mtb

2020-04-20 Thread Martin Koppenhoefer
Did you consider mtb=designated? Are there implications for pedestrians, riders and "other" cyclists? Motorbikes? (Question is, are they allowed, not allowed, or maybe allowed in absence of explicit specific access tags?) Cheers Martin ___ Tagging

Re: [Tagging] Too many different features lumped together under amenity=social_facility?

2020-04-20 Thread Martin Koppenhoefer
Am Mo., 20. Apr. 2020 um 19:01 Uhr schrieb Paul Allen : > Because "amenity" has come to mean "miscellaneous." > this is trolling, because amenity=social_facility social_facility=food_bank still has amenity as the "main" key, if we made it amenity=food_bank we would not change anything in this

Re: [Tagging] Too many different features lumped together under amenity=social_facility?

2020-04-20 Thread Martin Koppenhoefer
Am Mo., 20. Apr. 2020 um 16:41 Uhr schrieb Joseph Eisenberg < joseph.eisenb...@gmail.com>: > I would suggest deprecating social_facility=hospice, and I'm also not > convinced that social_facility=nursing_home is better than > amenity=nursing_home. interestingly, these 2 tags also haven't been

Re: [Tagging] Too many different features lumped together under amenity=social_facility?

2020-04-20 Thread Martin Koppenhoefer
Am Mo., 20. Apr. 2020 um 16:27 Uhr schrieb Paul Allen : > > Is it or is it not a social facility within the broad meaning of the term? > I'd say that it is. It's a facility. It's social (in both meanings: > people > interact socially and it is a social service). > apart from workshops, it is

Re: [Tagging] Points vs Polygons

2020-04-19 Thread Martin Koppenhoefer
sent from a phone > On 19. Apr 2020, at 20:29, Justin Tracey wrote: > > Another major exceptions where mapping as an internal node is better, IME, > are notable (historical) buildings that currently house a business. More > generally, if the tags of the building and business would conflict

Re: [Tagging] Points vs Polygons

2020-04-19 Thread Martin Koppenhoefer
vantageous. advantageous I meant ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Points vs Polygons

2020-04-19 Thread Martin Koppenhoefer
Am So., 19. Apr. 2020 um 17:53 Uhr schrieb Robert Castle < castler...@gmail.com>: > I noticed that some businesses are polygons whereas others are points > within a polygon. I was wondering which way is correct. > both is correct, although they are not equal. With polygons, you also convey

Re: [Tagging] iD semi automatic adding public_transport to aerialway=station

2020-04-19 Thread Martin Koppenhoefer
sent from a phone > On 19. Apr 2020, at 10:53, Jo wrote: > > It only makes sense if the teleférico can be used all year around and is > useful for the whole public. If it's only there to get skiers up a mountain, > I don't think it's part of the public transport network. I don’t agree

Re: [Tagging] iD semi automatic adding public_transport to aerialway=station

2020-04-19 Thread Martin Koppenhoefer
sent from a phone > On 18. Apr 2020, at 23:13, Gegorian Hauser wrote: > > I know that in the aerialway=station wiki site is nothing written about > public_transport. > But there should be the description about when the public_transport tagging > is allowed and when not for all kinds of

Re: [Tagging] Tagging a warehouse or distribution centre?

2020-04-19 Thread Martin Koppenhoefer
sent from a phone > On 19. Apr 2020, at 01:37, Joseph Eisenberg > wrote: > > and the landuse is > landuse=industrial (+ industrial=distributor or industrial=warehouse) > - https://wiki.openstreetmap.org/wiki/Key:industrial This page doesn’t seem to indicate that distribution and logistics

Re: [Tagging] Tagging a warehouse or distribution centre?

2020-04-19 Thread Martin Koppenhoefer
sent from a phone > On 19. Apr 2020, at 01:37, Joseph Eisenberg > wrote: > > Do we need another tag like man_made=distribution_centre, or is > landuse + building enough in this case? Why would it depend on the case? The building tag is about buildings and the landuse tag about landuse, so

Re: [Tagging] Refining heritage tag

2020-04-17 Thread Martin Koppenhoefer
sent from a phone > On 18. Apr 2020, at 01:04, Paul Allen wrote: > > The fraction of heritage POIs which are > protected areas is less than 1%. I still don’t see why we would need a new tag heritage_title rather than the established protection_title Maybe protected “area” is a strange tag

Re: [Tagging] Refining heritage tag

2020-04-17 Thread Martin Koppenhoefer
sent from a phone > On 18. Apr 2020, at 00:08, António Madeira wrote: > > I know there are many ref tags that don't follow this procedure, but if this > is useful why not starting to adopt it for some schemes like this one? because it leads to key bloat. It makes evaluation harder or more

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

2020-04-17 Thread Martin Koppenhoefer
sent from a phone > On 16. Apr 2020, at 23:33, António Madeira wrote: > > Do we divide big schools from small schools? Or small theatres from big > theatres? things can change nature just by changing size or quantity. We have different tags for a single tree and a tree row and a forest.

Re: [Tagging] Refining heritage tag

2020-04-17 Thread Martin Koppenhoefer
Am Fr., 17. Apr. 2020 um 04:27 Uhr schrieb António Madeira via Tagging < tagging@openstreetmap.org>: > After communicating with lutz from Historic.Place, he told me they didn't > create this heritage scheme, they just adopted it. > I took the opportunity to present him my proposal of refining

Re: [Tagging] Feature Proposal - RFC - Pumps (wells and many other things)

2020-04-16 Thread Martin Koppenhoefer
sent from a phone > On 13. Apr 2020, at 01:11, François Lacombe wrote: > > It is still proposed to discourage pump=powered/manual as they're at least > redundant with proposed classification of pumps/drivers technologies. aren’t manual pumps powered as well? (human powered?) Manual means

Re: [Tagging] Footways where pedestrians may only walk in one direction: oneway:foot=yes or foot:backward=no?

2020-04-16 Thread Martin Koppenhoefer
Am Do., 16. Apr. 2020 um 13:50 Uhr schrieb Andrew Harvey < andrew.harv...@gmail.com>: > But on a highway=footway,cycleway,path you can't drive a vehicle, so in > those cases if there is a oneway=yes it's fair to assume it applies to all > modes of transport on that way, unless otherwise

Re: [Tagging] Footways where pedestrians may only walk in one direction: oneway:foot=yes or foot:backward=no?

2020-04-16 Thread Martin Koppenhoefer
Am Do., 16. Apr. 2020 um 12:48 Uhr schrieb Warin <61sundow...@gmail.com>: > On 16/4/20 7:59 pm, Martin Koppenhoefer wrote: > > sent from a phone > > > On 16. Apr 2020, at 05:04, Joseph Eisenberg > wrote: > > Some paths and footways have oneway=yes. Sometimes th

Re: [Tagging] insurance health

2020-04-16 Thread Martin Koppenhoefer
sent from a phone > On 16. Apr 2020, at 11:41, Marc Gemis wrote: > > It's a health fund, and every adult Belgian needs to have one judging by their names, are they all mutual insurance companies? Cheers Martin ___ Tagging mailing list

Re: [Tagging] Footways where pedestrians may only walk in one direction: oneway:foot=yes or foot:backward=no?

2020-04-16 Thread Martin Koppenhoefer
sent from a phone > On 16. Apr 2020, at 05:44, Shawn K. Quinn wrote: > > foot:backward=no may make sense > to someone who has already read the wiki or other documentation, but is > confusing and has the double negative aspect to it. there is no double negative to it, it is a simple

Re: [Tagging] Footways where pedestrians may only walk in one direction: oneway:foot=yes or foot:backward=no?

2020-04-16 Thread Martin Koppenhoefer
sent from a phone > On 16. Apr 2020, at 05:04, Joseph Eisenberg > wrote: > > Some paths and footways have oneway=yes. Sometimes this means that > bicycles may only access these features in one direction, but other > times it has been used for one-way features for pedestrians (for > example,

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

2020-04-15 Thread Martin Koppenhoefer
Am Mi., 15. Apr. 2020 um 17:37 Uhr schrieb Manon Viou : > Hello again Martin, > I agree large and small are quite relative concepts, I proposed to set a > threshold to "less than 5 buildings" because it was the easiest way I > found. I'm not sure counting people is feasible at least for remote

Re: [Tagging] insurance health

2020-04-15 Thread Martin Koppenhoefer
Am Mi., 15. Apr. 2020 um 16:05 Uhr schrieb Frederik Ramm < frede...@remote.org>: > and a proper staffed office in a city. These sales representatives are > usually self-employed and get a kickback from every contract they sell. indeed, it wouldn't even be important where they are, because you

Re: [Tagging] insurance health

2020-04-15 Thread Martin Koppenhoefer
Am Mi., 15. Apr. 2020 um 15:55 Uhr schrieb Greg Troxel : > If there is a preset for "insurance" and a subtype for what kind, I > think most people would complete their tagging in seconds. And this is > something that isn't super common, and many people mapping it will be > tagging one, very

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

2020-04-15 Thread Martin Koppenhoefer
sent from a phone > On 15. Apr 2020, at 10:17, Manon Viou wrote: > > amenity=refugee_site and amenity=social_facility + social_facility=shelter. > amenity=refugee_site is for large refugee site > amenity=social_facility and social_facility=shelter is f or small refugee > site (less than 5

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

2020-04-15 Thread Martin Koppenhoefer
sent from a phone > On 15. Apr 2020, at 01:13, Warin <61sundow...@gmail.com> wrote: > > I would think amenity=refugee_site is an area set aside for the non-temporary > residential use of refugees maybe I’m a dreamer, but I would expect all refugee related features to be “temporary”, even

Re: [Tagging] insurance health

2020-04-15 Thread Martin Koppenhoefer
sent from a phone > On 15. Apr 2020, at 03:17, Joseph Eisenberg > wrote: > > But it takes more time for each mapper to add 2 tags instead of one. > Mapper time is the most precious resource in OpenStreetMap: we don't > have enough mappers, and most are working for free, for fun. > Let's make

Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand

2020-04-14 Thread Martin Koppenhoefer
Am Mo., 13. Apr. 2020 um 14:16 Uhr schrieb : > Hi, > oh sorry you are confused. Maybe it's too much text I think. But your > conclusion is completely correct, yes. > > Did you have a look at the currently used values for traffic_signals?

Re: [Tagging] city limit sign end

2020-04-14 Thread Martin Koppenhoefer
Am Di., 14. Apr. 2020 um 11:18 Uhr schrieb Volker Schmidt : > OK, > > we seem to agree that city-limit-begin sign needs to have angle or > cardinal direction values and not forward|backward, because it is often or > nearly always, on a joining node of two ways due to the implied speed limit > in

Re: [Tagging] city limit sign end

2020-04-14 Thread Martin Koppenhoefer
sent from a phone > On 13. Apr 2020, at 00:52, Marc M. wrote: > > we do the same for stop, give_away, ... > and those ways may also be splitted > if both ways are in the same direction, this is equally disputed and should be discouraged as well > the direction is just > as understandable

Re: [Tagging] Things within things | Re: Request for assistance in creating a tag.

2020-04-13 Thread Martin Koppenhoefer
sent from a phone > On 13. Apr 2020, at 11:29, Rory McCann wrote: > > OSM could do much better for indoor mapping, and for shopping centres or > train stations, that's easy. Add each `shop` or corridor. But what about a > (sorta of) clinic within a larger OSM object? it‘s a similar

Re: [Tagging] city limit sign end

2020-04-12 Thread Martin Koppenhoefer
sent from a phone > On 12. Apr 2020, at 13:54, Alexey Zakharenkov wrote: > > direction=backward is invalid value in this context. The road is often split > at city_limit node to reflect the change in highway properties (primarily > max_speed), and backward/forward notion is undefined for an

Re: [Tagging] building=public vs. building=civic

2020-04-08 Thread Martin Koppenhoefer
sent from a phone > On 8. Apr 2020, at 12:35, Steve Doerr wrote: > > Whether that's what it means in OSM is another matter. While building=public seems defined, I have difficulties with building=civic, which is according to the wiki

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

2020-04-07 Thread Martin Koppenhoefer
sent from a phone > On 7. Apr 2020, at 11:41, Andrew Davidson wrote: > > boundary=national_park is an *existing* tag that is used to tag "a relatively > large area of land" that is "set aside for human recreation and enjoyment, as > well as the protection of the natural environment and/or

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

2020-04-07 Thread Martin Koppenhoefer
sent from a phone > On 7. Apr 2020, at 09:28, Joseph Eisenberg wrote: > > But if Wikidata is already storing this info, maybe we don’t need a tag for > it? if the information is useful for us, or maybe even essential to understand the nature of the thing, then we should have the

Re: [Tagging] building=public vs. building=civic

2020-04-07 Thread Martin Koppenhoefer
Although I also see a lot of overlap, I could imagine public buildings to be a bigger category of which civic buildings are only a part, according to your culture and context, one could imagine public buildings that aren’t civic buildings such as churches and temples. I could also imagine

Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap

2020-04-06 Thread Martin Koppenhoefer
sent from a phone > On 6. Apr 2020, at 16:51, Paul Allen wrote: > >> or use https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID > > I didn't even know that existed. I'm not sure I trust such IDs to survive > intensive editing by newbies who can delete an object then add it > with

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

2020-04-06 Thread Martin Koppenhoefer
Am Mo., 6. Apr. 2020 um 14:00 Uhr schrieb Kevin Kenny < kevin.b.ke...@gmail.com>: > That would also allow us to address Joseph Eisenberg's objection (in > the talk page on the WIki) that the proposal violates the 'one object, > one tag' principle. there is no such principle (AFAIK a principle

Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap

2020-04-06 Thread Martin Koppenhoefer
Am Mo., 6. Apr. 2020 um 10:13 Uhr schrieb Frederik Ramm : > Secondly, this is a problem shared by all the "last survey" approaches: > You're standing the logic on its head. You're essentially saying: "If > the object has NOT changed in reality, please DO change it in OSM" (by > updating the

Re: [Tagging] Can highway=cycleway be limited to MTB?

2020-04-05 Thread Martin Koppenhoefer
Am So., 5. Apr. 2020 um 11:03 Uhr schrieb Yves : > As a side note: I would be worried to redefine the mtb=yes/no tag that is > not documented but widely used. > how can it be "redefined" if there isn't documentation about it? Cheers Martin ___

Re: [Tagging] Can highway=cycleway be limited to MTB?

2020-04-04 Thread Martin Koppenhoefer
Am Sa., 4. Apr. 2020 um 13:21 Uhr schrieb Morten Lange via Tagging < tagging@openstreetmap.org>: > > >> We're on the edge of tags definition : this a path limited > cyclist, > > >> where a mountain bike almost mandatory to ride there. Some > features > > >> help the cyclist. > > > > >

<    1   2   3   4   5   6   7   8   9   10   >