Re: [Tagging] relations & paths
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 shorter routes as being 'wrong'? On Mon, May 11, 2020 at 10:17 PM brad wrote: > > I see a lot of relations, type:route, which are only short > trails/paths. This is wrong isn't it? Do you suppose that folks are > doing this to get better rendering? > Brad > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging -- 73 de ke9tv/2, Kevin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] relations & paths
Can you point to some examples? In Belgium and The Netherlands we have node-networks. and some of the routes that are mapped in those networks can be pretty short. The shortest I know is only a few meters long: https://www.openstreetmap.org/relation/1696883#map=19/51.01511/4.44965 regards m. On Tue, May 12, 2020 at 4:17 AM brad wrote: > > I see a lot of relations, type:route, which are only short > trails/paths. This is wrong isn't it? Do you suppose that folks are > doing this to get better rendering? > Brad > > ___ > 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] relations & paths
I see a lot of relations, type:route, which are only short trails/paths. This is wrong isn't it? Do you suppose that folks are doing this to get better rendering? Brad ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tag:amenity=motorcycle_taxi not approved
On Mon, 11 May 2020 at 11:25, Joseph Eisenberg wrote: > If you arrive at the airport in Bali with your in-laws, and look on Maps.me > for the closest taxi stand and walk over to it, you will be quite > disappointed to find a line of motorcycles, and have to walk back to the > other side of the airport to get a cab at the real taxi stand. > > This is not a problem in your country, because you only have taxicab stands. > It will not affect you personally, unless you travel to Asia or Africa etc. 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. Or is it "tagging for Maps.me", which might not be adapted to differently render amenity=taxi + taxi=motorcycle_taxi on short notice? Luckily they do change rendering for some subtags: amenity=parking + access=private; or railway=station + wheelchair=*. (And what about water taxis at Malé airport?) --Jarek ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme
On Mon, 11 May 2020 at 19:30, Shawn K. Quinn wrote: > > In fact, I'm not sure how useful it is for us to tag phone numbers on > phoneboxes at all. Does anyone actually use this data for something useful? > Your local drug-dealers so people can ring them at the phone box? :-) On Mon, 11 May 2020 at 20:18, s8evq wrote: > Do we have a lot of keys with double meaning, where you need to look at > the which keys are also on the object to figure out the true meaning? > =taxi & =motorcycle_taxi? :-) Thanks Graeme ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tag:amenity=motorcycle_taxi not approved
This seems very logical. This is very evident jn Thailand also. Its like every 2 blocks in Bangkok there is a motorcycle taxi stand. On Mon, May 11, 2020 at 11:26 PM Joseph Eisenberg < joseph.eisenb...@gmail.com> wrote: > You guys, we are not talking about mapping a taxi call centre, where you > use a phone number to order a cab. We are talking about mapping a taxicab > queue or stand: a spot where taxis wait for passengers. > > Of course if you have 8 people in your part, and walk up to a taxicab > stand, they might tell you that you need 2 cars (though in many some > countries they will let you pile in to one car with your luggage strapped > to the roof.. ). But you will be able to get a cab. > > If you arrive at the airport in Bali with your in-laws, and look on > Maps.me for the closest taxi stand and walk over to it, you will be quite > disappointed to find a line of motorcycles, and have to walk back to the > other side of the airport to get a cab at the real taxi stand. > > This is not a problem in your country, because you only have taxicab > stands. It will not affect you personally, unless you travel to Asia or > Africa etc. > > -Joseph Eisenberg > > On Mon, May 11, 2020 at 1:04 AM Marc M. wrote: > >> Hello, >> >> Le 10.05.20 à 01:24, Martin Koppenhoefer a écrit : >> > imagine you are ordering a taxi for yourself and 2 colleagues to the >> > airport and instead of a taxi (cab) they send you 3 taxi moto. Would >> > that be equally ok, wouldn’t it matter, taxi is taxi? >> >> Imagine ordering a taxi and arriving in a 4-seater car when you have >> a family of 8, it's the same problem, isn't it? >> When I order a taxi, they ask me the number of people. >> the guy won't come with a fiat 500 if I say 8 >> >> 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 : one traffic sign for for all variants. >> >> Regards, >> Marc >> >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- *MIKKO L. TAMURA* *Administrator* *Map Beks Initiative* *Externals Head* *Pilipinas Chubs X Chasers* *Volunteer Mapper* *OpenStreetMap Philippines* *Contact Number: +639052320416* ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tag:amenity=motorcycle_taxi not approved
You guys, we are not talking about mapping a taxi call centre, where you use a phone number to order a cab. We are talking about mapping a taxicab queue or stand: a spot where taxis wait for passengers. Of course if you have 8 people in your part, and walk up to a taxicab stand, they might tell you that you need 2 cars (though in many some countries they will let you pile in to one car with your luggage strapped to the roof.. ). But you will be able to get a cab. If you arrive at the airport in Bali with your in-laws, and look on Maps.me for the closest taxi stand and walk over to it, you will be quite disappointed to find a line of motorcycles, and have to walk back to the other side of the airport to get a cab at the real taxi stand. This is not a problem in your country, because you only have taxicab stands. It will not affect you personally, unless you travel to Asia or Africa etc. -Joseph Eisenberg On Mon, May 11, 2020 at 1:04 AM Marc M. wrote: > Hello, > > Le 10.05.20 à 01:24, Martin Koppenhoefer a écrit : > > imagine you are ordering a taxi for yourself and 2 colleagues to the > > airport and instead of a taxi (cab) they send you 3 taxi moto. Would > > that be equally ok, wouldn’t it matter, taxi is taxi? > > Imagine ordering a taxi and arriving in a 4-seater car when you have > a family of 8, it's the same problem, isn't it? > When I order a taxi, they ask me the number of people. > the guy won't come with a fiat 500 if I say 8 > > 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 : one traffic sign for for all variants. > > Regards, > Marc > > ___ > 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] Remove non-prefixed versions of 'contact:' scheme
On 11.05.2020 03:10, Paul Allen wrote: > I'm far from convinced that contact:website is useful. It's certainly > semantically wrong. It's a contact;webpage not a contact:website > (there are maybe a handful of exceptions to that). Why do you think > the user is more likely to require the webpage giving contact details > rather than the home page of the web site? I'd expect users are > more likely to want more information on what a POI is than to > want to find out how to contact it. > > I find the whole contact: namespace to be ill-conceived. But fine, if > you want it then use it. Just please stop suggesting that we > deprecate website=* and phone=*. Indeed the main reason why my preference is not to use the contact:* scheme is that its proponents did not limit the scheme to true means of contacting, but tried to press everything into it that was not up in the trees when counting to three. The most prominent example is website, where only a page with a message form would be clearly in this category. However what is more recommended to be mapped is the basic homepage of a POI, because it is least likely to be changed in website relaunches. The main purpose for me to read a website is to gain information about the object and not to contact it. In countries where an imprint is not mandatory, websites often do not even provide contact details at all. There are many more examples on the contact:* wiki page that are pure methods of dissemination and not of contact, such as contact:youtube or even contact:flickr How is contact:webcam supposed to fit into the scheme? In contrast, postal addresses are a very typical means of contact, I can send a letter there. So consequently, we would have to to move the "addr:*" scheme into "contact:addr:*", which would make the scheme even more stilted. I guess that contact:[phone|fax|email], and nothing more, could have won easily if the scheme had not tried to include all the other stuff. tom ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tag:amenity=motorcycle_taxi not approved
May 11, 2020, 13:43 by dieterdre...@gmail.com: > 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 <>>> ja...@piorkowski.ca>>> > >>> 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 with >>> amenity=parking is similar to tagging the shower in your home as >>> amenity=shower or your kitchen sink as amenity=drinking_water. >>> >> Not really. Private parking are worth mapping - it is stiil useful for >> orientation, data analysis, >> QA (private parkings vs unmapped) etc >> > > > right, but this doesn't mean it must have the same main tag, in particular > "amenity" as key. For example we do not map private post boxes (your incoming > mail) the same as those from the postal service for outgoing mail, although > in the beginning there have been proponents to use amenity=post_box, > access=private ;-) > This is problematic because it makes impossible to map parking from aerial images. You would need three top level tags - for unknown access status, known as accessible, and known to be private. >> Tagging private showers, kitchens and toilets is unacceptable and should be >> deleted if spotted. >> >> > > > can you point to the rule? What would not be acceptable is tagging them like > the amenities. > I would delete it (and deleted in past) as a blatant privacy violation. There is attempt to define it more explicitly at https://wiki.openstreetmap.org/wiki/Limitations_on_mapping_private_information ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme
May 11, 2020, 15:04 by tagging@openstreetmap.org: > I would also advocate to focus on parts of tagging that > are without known long-standing gridlock. > > Like contact:phone vs phone. > To clarify: I advocate avoiding known messes like phone vs contact:phone - this one will not be ever resolved and that it is OK. There are many open tagging issues (or simply things to map) where attention is more useful. -- signed, person who is probably spending too much time on tagfidling anyway. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme
May 11, 2020, 03:47 by cjmal...@mail.com: > On Mon, 2020-05-11 at 02:10 +0100, Paul Allen wrote: > >> And yet you, and others, keep saying it. "Deprecate" means "express >> disapproval of." In the context of OSM, it means "phase out." That >> is, >> eradicate with the passage of time. It may not be what you mean, but >> it's what you keep saying. >> > > Any yet what I described was a phase out with 3 steps. > "phase out with 3 steps", "deprecate". "get rid of", "eliminate", "gradually deprecating" all mean that the plan is to eliminate the tag. They subtly differ in how this elimination would exactly work, but all describe process of removing tag from use. Number of steps, length of process is not changing that. It is perfectly fine to deprecate/eliminate tags that are harmful, I started or helped this process with numerous ones. But trying to eliminate tag and avoiding calling it deprecation/elimination is silly. I would also advocate to focus on parts of tagging that are without known long-standing gridlock. Like contact:phone vs phone. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme
On Mon, 11 May 2020 at 13:51, Marc M. wrote: > Le 11.05.20 à 14:42, Paul Allen a écrit : > > On Mon, 11 May 2020 at 10:58, s8evq wrote: > > What's you counter argument to the people suggesting that contact:* > > makes it easier for data consumers to gather all contact info in one > > go, instead of hard coding all the possible keys. What if next year > > a new way of contacting comes up? > > > > For mappers, no purpose. They use the editor preset > > your answer is precisely the *problem* in the question > every new contact need a new preset in stead of query taginfo > and show top X contact:* > Good point. And, since we have hundreds of new ways of tagging contacts appearing every day, very much needed. Oh, we don't have new ways of tagging contacts appearing every day. Or even every month. On average, maybe once a year (if I'm being generous). I'm not entirely convinced this is a problem worth solving. same problem for the user of the data. if somebody wants to display > all the details of a shop, he has to make a hardcoded list of phone > website... instead of being able to display all the contacts:* that > the osm contributor has filled in. > Good point. I can't count all the times I've wanted all the contact details of a POI but NONE of the other details like the name, the address, what type of POI it is, etc. Well, actually, I can. Zero. OTOH, there are a lot of times I've wanted to know more about a POI but not been interested in the contact details. But even if you're correct, why are the results of the query tool in standard carto unsuited to your needs? Are you going to propose changes to the tool so that, if the user wishes, it returns only the contact details and no other information about the POI? -- Paul ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme
On Mon, 11 May 2020 at 02:48, Cj Malone wrote: > On Mon, 2020-05-11 at 02:10 +0100, Paul Allen wrote: > > And yet you, and others, keep saying it. "Deprecate" means "express > > disapproval of." In the context of OSM, it means "phase out." That > > is, > > eradicate with the passage of time. It may not be what you mean, but > > it's what you keep saying. > > Any yet what I described was a phase out with 3 steps. > "Phase out": "to discontinue the practice, production, or use of by phases. intransitive verb. : to stop production or operation by phases." So you explicitly state that you do not wish to get rid of the phone tag yet continue to find different ways of implicilty saying that you wish to get rid of the phone tag. Is English not your first language? I thought this mailing list was the official avenue for disusing, > changing and adding tags in OSM. I didn't realise you had to get the > editor permission. > Unless you get editor buy-in then your shiny new tag won't get used by many people because it's not offered as an editor preset. Because it doesn't get used much, authors of editors will say they're not including it as a preset because it's not popular. You may not like that. I certainly don't like that. But it's how it is. > > > Oh, and there's all the legacy usage you have to clean up, except > > we don't like automated edits. But without cleaning it up, you make > > database queries more complex. > > I don't have any arguments against automated edits, bulk edits, machine > assisted edits. In any dataset they are needed, especially one this > massive. But it's not a fight I have the effort to fight right now. > Very wise. Because you have to have very, very strong justification for automated edits in OSM. The most fundamental precondition is that ALL a=b change to x=y. And even if you satisfy that precondition, it probably won't be permitted. And we already know you don't satisfy that precondition because the phone number for a phone box is not a contact phone number and various websites are not contact pages. > > > I am far from convinced that a contact phone number is not a phone > > number. > > If I see a phone=* on a phone box I know it is not a contact number. > > If > > I see a phone=* on a business I know it's a contact phone number for > > the business. What extra utility does having contact:phone provide? > > And is it worth the hassle of manually editing all the existing tags > > to > > fix? > > That's just one edge case with the phone tag. Another one being phone > on parking. Is that the number you call to pay, or is it the number you > call to contact the operator because there is something wrong. > So it's a phone number you call if you want to talk to somebody a POI. That's an edge case how? > > I believe there are more edge cases we still aren't thinking of, and if > we aren't the user agents defiantly aren't. > I don't think you've found any edge cases yet. I don't think there are any edge cases unless you can find one where a contact phone number isn't a phone number. Amusingly, the more arguments you put forward the more convinced I am that contact:* is a horrible idea without merit. -- Paul ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme
Le 11.05.20 à 14:42, Paul Allen a écrit : > On Mon, 11 May 2020 at 10:58, s8evq wrote: > What's you counter argument to the people suggesting that contact:* > makes it easier for data consumers to gather all contact info in one > go, instead of hard coding all the possible keys. What if next year > a new way of contacting comes up? > > For mappers, no purpose. They use the editor preset your answer is precisely the *problem* in the question every new contact need a new preset in stead of query taginfo and show top X contact:* same problem for the user of the data. if somebody wants to display all the details of a shop, he has to make a hardcoded list of phone website... instead of being able to display all the contacts:* that the osm contributor has filled in. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme
On Mon, 11 May 2020 at 10:58, s8evq wrote: > Hi Paul, > > On Mon, 11 May 2020 02:10:12 +0100, Paul Allen wrote: > > I find the whole contact: namespace to be ill-conceived. But fine, if > > you want it then use it. Just please stop suggesting that we > > deprecate website=* and phone=*. > > What's you counter argument to the people suggesting that contact:* makes > it easier for data consumers to gather all contact info in one go, instead > of hard coding all the possible keys. What if next year a new way of > contacting comes up? > Since you ask... What purpose does that actually serve? For mappers, no purpose. They use the editor preset and get phone=* or contact:phone=* depending upon what the author of the editor thinks is the right way to do it. No purpose for mappers who enter raw tags either - it's easy enough to create a wiki page for "Contact Tags" and list phone, website, fax, telepathy, etc. Maybe, just maybe, for newbies who aren't sure of what contact tags are available and want to be able to type "contact" into the editor and get a list of possibilities, but some editors do searches of brief tag descriptions that would achieve the same thing. But I'd argue most mappers operate on "I have a phone number for this POI, how do I tag it?" rather than "What contact methods are available for POIs, when I know that I'll check if this POI has any of them." For users, little purpose. They use the query tool in standard carto (or similar tool in other cartos) and get a list of tags. If a POI had dozens of tags then grouping the contact tags in one place might be slightly helpful, but in most cases not. For carto, no purpose. They ignore tags unless somebody has specifically put in handling code for them. They don't (and probably won't) render POIs with some form of contact tag any differently, so it doesn't matter if they don't code for phone=* or don't code for contact:phone=* because not coding to handle a tag requires no effort. For data queries, maybe a purpose. But first you have to convince me that anybody would have reason to perform such a query. Bring up overpass-turbo, move the map to a particular area, and find all the POIs which have any method of contacting them. Why would anybody want to do this? And if you can come up with a reason, how often is this likely to happen? Often enough that it's worth all the hassle of contact:*=* so that somebody can build a query on "contact:*=*" rather than "phone=* and website=* and fax=* and whatever=*"? The only purpose I've seen anybody mention for contact:phone is for a phone number to contact a car park's operator. And even that doesn't really seem justified. It's a phone number for a POI. The phone isn't physically at the POI but it's the number you dial to talk to the operator of the POI. I don't see any reason to make a distinction. I've yet to see anybody explain what a phone number is for other than to contact somebody. There are fax numbers, but they would be better handled by fax=*. As Gertrude Stein didn't say, a phone number is a phone number is a phone number. The contact: namespace seems to be taxonomic hierarchy for taxonomic hierarchy's sake. -- Paul ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme
Le 11.05.20 à 11:29, Shawn K. Quinn a écrit : > In fact, I'm not sure how useful it is for us to tag phone numbers on > phoneboxes at all. Does anyone actually use this data for something useful? it look like a ref, and a ref is useful to link 2 databases, including if we put it in the ref key :) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tag:amenity=motorcycle_taxi not approved
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 then you also need to know to check for > access!=private. > > > > this is indeed an unfortunate choice. Tagging a private access parking > with amenity=parking is similar to tagging the shower in your home as > amenity=shower or your kitchen sink as amenity=drinking_water. > > Not really. Private parking are worth mapping - it is stiil useful for > orientation, data analysis, > QA (private parkings vs unmapped) etc > right, but this doesn't mean it must have the same main tag, in particular "amenity" as key. For example we do not map private post boxes (your incoming mail) the same as those from the postal service for outgoing mail, although in the beginning there have been proponents to use amenity=post_box, access=private ;-) > > Tagging private showers, kitchens and toilets is unacceptable and should > be deleted if spotted. > > can you point to the rule? What would not be acceptable is tagging them like the amenities. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme
+1 I find you wrote down very sound and logical arguments. Splitting phone into "a way of contacting a business" and "a telephone number of a phonebooth" sounds logic. Counterargument is that you can figure this out by the fact that phone=* + shop=* means it's a business number. phone+amenity=telephone means it's a phonebox' number. So there can not be confusion. How is the general OSM consensus on this. Do we have a lot of keys with double meaning, where you need to look at the which keys are also on the object to figure out the true meaning? On Mon, 11 May 2020 01:36:51 +0100, Cj Malone wrote: > On Sun, 2020-05-10 at 23:07 +0100, Paul Allen wrote: > > But that's what they often imply. > > I don't know if this is worth saying or not, but this isn't a war, > there aren't sides. We all just want OSM to be the best it can be. > > I am fairly new to OSM, especially the mailing lists but I guess you > are coming from a point of view like "They are coming for the phone tag > again". I'm not, I wasn't part of any previous discussions on the phone > tag or contact namespace. I just want to help improve OSM, any way that > I can. > > If you are a little annoyed because you've had this discussion multiple > times that just means it's a hot topic for people and discussions will > help everyone understand all the other opinions. > > > > and gradually deprecating the generic tags. > > > > And there you go, wanting to get rid of phone=* and website=*. > > I think I stand by that quote, but I'm happy to discus it. I'm not > arguing that over night we should stop people using the phone tag. > 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 incoming phone number and > phone is defined as the contact number. I'm OK with that too, it's the > definitions that really matter. > > As this conversation has gone on, I now believe that contact:phone and > phone are separate things. As such I believe phone is massively misused > as a contact number and so should actually be contact:phone. Lets > gradually move people away from this. > > - We can start with documenting the differences between the tags on the > Wiki. > - Lets get the editors to push mappers use the accurate tag, is this a > contact number, or another form of number. > - And then lets start informing OSM maintainers about the ambiguous use > of phone and give warnings to use a more quantified tag. > > The above 2 paragraphs might be easier to think of context of website > and contact:website. I have previously misused them, I have been adding > contact:website that are web pages for the specific store, but just > have a contact number and address. That's not a contact method and so > doesn't belong in contact:website. > > > > ___ > 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] Remove non-prefixed versions of 'contact:' scheme
Hi Paul, On Mon, 11 May 2020 02:10:12 +0100, Paul Allen wrote: > I find the whole contact: namespace to be ill-conceived. But fine, if > you want it then use it. Just please stop suggesting that we > deprecate website=* and phone=*. What's you counter argument to the people suggesting that contact:* makes it easier for data consumers to gather all contact info in one go, instead of hard coding all the possible keys. What if next year a new way of contacting comes up? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tag:amenity=motorcycle_taxi not approved
May 11, 2020, 10:06 by dieterdre...@gmail.com: > > > 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 with > amenity=parking is similar to tagging the shower in your home as > amenity=shower or your kitchen sink as amenity=drinking_water. > Not really. Private parking are worth mapping - it is stiil useful for orientation, data analysis, QA (private parkings vs unmapped) etc Tagging private showers, kitchens and toilets is unacceptable and should be deleted if spotted. (note that some amenity=toilets + access=private should be retagged to access=customers rather than deleted) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme
On 5/10/20 7:36 PM, Cj Malone wrote: > I think I stand by that quote, but I'm happy to discus it. I'm not > arguing that over night we should stop people using the phone tag. > 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 incoming phone number and > phone is defined as the contact number. I'm OK with that too, it's the > definitions that really matter. Why should we split these out? In fact, I'm not sure how useful it is for us to tag phone numbers on phoneboxes at all. Does anyone actually use this data for something useful? -- Shawn K. Quinn http://www.rantroulette.com http://www.skqrecordquest.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme
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 incoming phone number and > phone is defined as the contact number. I'm OK with that too, it's the > definitions that really matter. if you get rid of the idea that "contact number" merits its own specific key, then you can see them both as "incoming numbers" and there is just a single use instead of 2. At that point, abandon "contact:phone" as that catches only 1 of the 2 cases you identified, and you are left with "phone" which is ok for all use cases. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tag:amenity=motorcycle_taxi not approved
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 : one traffic sign for for all variants. can you show the traffic sign for motorcycle taxi waiting areas? IMHO “normal” cars are for up to 8 passengers, if there are more seats it is a bus, different sign, different rules, not a taxi. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tag:amenity=motorcycle_taxi not approved
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 with amenity=parking is similar to tagging the shower in your home as amenity=shower or your kitchen sink as amenity=drinking_water. Or tagging amenity=drinking_water with drinking_water=no (IIRR, someone once proposed this combination for water taps that do not provide drinking water). These should all be avoided, and just because it became established for parkings (where there are also edge cases like customer parking), does not imply we should do it for more tags. > If you're doing an analysis of mobility options then > you need to know to check for wheelchair tag, etc. different case. This is an example how it should work: a shop remains a shop, a pub a pub and a sidewalk a sidewalk, regardless of the wheelchair tag. This tag doesn’t make a pub a fast food or a fine dining restaurant. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tag:amenity=motorcycle_taxi not approved
Hello, Le 10.05.20 à 01:24, Martin Koppenhoefer a écrit : > imagine you are ordering a taxi for yourself and 2 colleagues to the > airport and instead of a taxi (cab) they send you 3 taxi moto. Would > that be equally ok, wouldn’t it matter, taxi is taxi? Imagine ordering a taxi and arriving in a 4-seater car when you have a family of 8, it's the same problem, isn't it? When I order a taxi, they ask me the number of people. the guy won't come with a fiat 500 if I say 8 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 : one traffic sign for for all variants. Regards, Marc ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tag:amenity=motorcycle_taxi not approved
在 2020年5月11日週一 09:18，Jarek Piórkowski 寫道： > On Sun, 10 May 2020 at 21:04, Phake Nick wrote: > > I am more thinking about analysis of geographical data of cities or > districts where taxi and motorcycle taxi would be two very different things > to be managed. > > If you are managing taxis and motorcycle taxis then surely you know > you have to check which is which. Which tag is used to check for them > is immaterial. > Yes, but it would be impossible to check if the motorcycle tag become optional, aka when motorcycle become another value chained to the taxi tag. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
