Re: [Tagging] Lyft and nameless sectioning in OSM

You are using "zone" and that confuses me, because in the US zone is like zoning. Are we talking about landuse, or regulations for what land can be used for? I think it's reasonable to draw landuse=retail if it's actually true it's named and the boundary is more or less the property

Re: [Tagging] Lyft and nameless sectioning in OSM

Vào lúc 14:06 2022-10-11, Evan Carroll đã viết: This is also really well said, and we should not overlook that I'm new to OSM and don't know of the time when buildings were not mapped. I see all buildings mapped, and wonder why I need a container to tell me that all things in it are that which

Re: [Tagging] Lyft and nameless sectioning in OSM

On 10/11/22 19:45, Minh Nguyen wrote: None of this is particularly relevant to Houston, but I don't think there's any precedent or mechanism for formally deprecating a broadly defined tag in only the places that satisfy certain criteria. Houston has no zoning (the largest city in the US to not

Re: [Tagging] Lyft and nameless sectioning in OSM

Martin Koppenhoefer writes: > Actually I do not believe “commercial zone” is a good description of > landuse=commercial because it implies zoning (prescription, also > planning i.e. permissible future landuse as opposed to de facto use of > land) and because it implies a certain scale. I think

Re: [Tagging] Lyft and nameless sectioning in OSM

Andy Townsend writes: > I'd suggest asking them in the changeset about that edit, including > where they got the data from.  I'd also be perfectly reasonable to ask > them what the "proprietary sources" were that they used, Agreed. It would be more than reasonable to ask them about the

Re: [Tagging] Lyft and nameless sectioning in OSM

Shawn has it right as I see it, too, so I think he says it for all of us. Let's all say "there are regionalisms" and leave it at that (for now). Tags can (and do) express those. It's complicated, not terribly too much. And we tighten it up across stores (convenience or otherwise) as nodes and

Re: [Tagging] Feature Proposal - RFC - Historic

On Tue, 11 Oct 2022 at 23:28, Mateusz Konieczny via Tagging < tagging@openstreetmap.org> wrote: > > Maybe there would be value in deapproving historic=battlefield > I would love to be able to move the vast majority of military= to historic=military, as they are no longer military installations.

Re: [Tagging] Feature Proposal - Voting - Payment denominations

sent from a phone > On 10 Oct 2022, at 12:07, Michael Brandtner wrote: > > The proposal includes advice to only use this tag in shops that don't accept > all denominations in Italy, one and two cent coins have been abolished, they are not accepted any more in shops, and while prices are

Re: [Tagging] RFC - More sensible values for fountain=*

I do not like very much at all the key "new_key_describing_fountain_style" — if that is really a literal key you (Davidoskky) are proposing here. If it is a place-holder for what we eventually decide upon FOR the semantics of that key, then OK, I'm nodding my head and continue to listen /

Re: [Tagging] RFC - More sensible values for fountain=*

Am Mo., 10. Okt. 2022 um 09:53 Uhr schrieb Davidoskky via Tagging < tagging@openstreetmap.org>: > I do not believe > anymore that man_made=water_tap should be deprecated but rather > redefined to only describe the tap of a fountain and not the whole > fountain. > this is not a redefinition, it

Re: [Tagging] RFC - More sensible values for fountain=*

On 11/10/22 10:25, Martin Koppenhoefer wrote: Is it possible that drinking fountain in a given style has multiple models? absolutely yes. Would this be a problem at the current state of things? Nobody is tagging the specific model type, such as distinguishing nasone from the 1960s

Re: [Tagging] RFC - More sensible values for fountain=*

Oct 11, 2022, 12:27 by dieterdre...@gmail.com: > > > sent from a phone > > >> On 11 Oct 2022, at 11:30, Davidoskky via Tagging >> wrote: >> >> >> Nobody is tagging the specific model type, such as distinguishing >> nasone from the 1960s and nasone from the 1990s. >> >> >> Should we

Re: [Tagging] offlist about for

bad thread, sorry :( ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

[Tagging] RFC: Proposed features/Deprecate man made=drinking fountain

I created https://wiki.openstreetmap.org/wiki/Proposed_features/Deprecate_man_made%3Ddrinking_fountain#Examples I believe there is consensus to deprecate, but it is not unaminous so I created a proposal to confirm consensus. ___ Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - Historic

Thanks. Do you see a problem with approving a de facto key? On 11/10/2022 15:25, Mateusz Konieczny via Tagging wrote: I see no value in approving de facto key. Maybe there would be value in deapproving historic=battlefield Also, is "are of historic interest" mismatches how

Re: [Tagging] Feature Proposal - RFC - Historic

On 11/10/2022 15:25, Mateusz Konieczny via Tagging wrote: Maybe there would be value in deapproving historic=battlefield This is not in the scope of this proposal. Feel free to start a proposal do deapprove battlefield. ___ Tagging mailing list

Re: [Tagging] Proposal - RFC - Use model to describe fountains

On 11/10/22 15:22, Mateusz Konieczny via Tagging wrote: what happens when Rome start using new model of fountain in a given style? You would tag that as a new model. Style has many problems, because you could very well tag baroque fountains as a style or baroque fountains made by this

Re: [Tagging] Feature Proposal - RFC - Historic

Le 11.10.22 à 15:25, Mateusz Konieczny via Tagging a écrit : I see no value in approving de facto key. Maybe there would be value in deapproving historic=battlefield Also, is "are of historic interest" mismatches how historic=wayside_shrine historic=memorial many historic=wayside_cross are

Re: [Tagging] Feature Proposal - RFC - Historic

IMHO "historic" should not be a primary key at all.  Many ruins and memorials are "of historic interest" it is true, but that could be tagged as a property ("historic=yes") of the object "man_made=" . What about a modern memorial?  Can that be "of historic interest", if it is only 2 years old? 

Re: [Tagging] RFC - More sensible values for fountain=*

sent from a phone > On 11 Oct 2022, at 13:30, Davidoskky via Tagging > wrote: > > This is problematic, since if you only tag amenity=fountain it will fall back > to a decorative fountain since amenity=fountain appears to be defined in that > way. those fountains that supply drinking

Re: [Tagging] RFC - More sensible values for fountain=*

sent from a phone > On 11 Oct 2022, at 13:30, Davidoskky via Tagging > wrote: > > If I have a fountain that is not decorative, doesn't have a tap and doesn't > provide drinking water, this fountain cannot be tagged. why are you sure it is a fountain? And what has it to do with it having a

Re: [Tagging] advices about multiple values have inaccuracies , between several pages

Oct 11, 2022, 14:17 by marc_m...@mailo.com: > Hello, > > I find that advices about multiple values have inaccuracies > between several pages : > > https://wiki.openstreetmap.org/wiki/Any_tags_you_like#Syntactic_conventions_for_new_values > Properties can have a large number of possible values

Re: [Tagging] RFC - More sensible values for fountain=*

sent from a phone > On 11 Oct 2022, at 13:30, Davidoskky via Tagging > wrote: > > How would you tag this fountain I photographed the other day? > > The water is not potable, the stream of water cannot be interrupted and > definitely is not a decorative fountain. > >

Re: [Tagging] RFC: Proposed features/Deprecate man made=drinking fountain

Hello, Le 11.10.22 à 14:46, Mateusz Konieczny via Tagging a écrit : https://wiki.openstreetmap.org/wiki/Proposed_features/Deprecate_man_made%3Ddrinking_fountain#Examples I fully approve, especially the fact that it does not approve of the mix of other tags but only solves the issue with this

Re: [Tagging] Proposal - RFC - Use model to describe fountains

On 11/10/22 15:22, Mateusz Konieczny via Tagging wrote: but in general I support this idea, just key seems wrong. If you can advise better keys, please do that in the wiki discussion page so that good ideas are documented there and not lost in the mailing list. It might be good to have

[Tagging] Proposal - RFC - parking:position

|Hello list,| |I would like to simplify the tagging of parking lane positions (e.g. "on street" or "on kerb"). We have an established tagging for parking lanes (parking:lane=*), which allows to map the orientation and position of parked vehicles on the road. The proposal aims to change the

Re: [Tagging] Feature Proposal - RFC - Historic

Oct 11, 2022, 15:31 by martianfreeloa...@posteo.net: > > > On 11/10/2022 15:25, Mateusz Konieczny via Tagging wrote: > >> Also, is "are of historic interest" mismatches how >> historic=wayside_shrine >> historic=memorial >> many historic=wayside_cross >> are used. >> > > Do you have a

Re: [Tagging] Feature Proposal - RFC - Historic

No, as long as meaning is not being changed. Oct 11, 2022, 15:29 by martianfreeloa...@posteo.net: > Thanks. Do you see a problem with approving a de facto key? > > > > On 11/10/2022 15:25, Mateusz Konieczny via Tagging wrote: > >> I see no value in approving de facto key. >> >> Maybe there would

[Tagging] Feature Proposal - Rejected - Refine departures board tagging

I'm withdrawing the proposal from voting due to some mistakes that need fixing and the apparent need of more discussion on some points. On 10/10/2022 20:58, Dimitar wrote: |Voting has started for Refine departures board tagging.

Re: [Tagging] Proposal - RFC - Use model to describe fountains

again: it seems to be tagging style, not specific model what happens when Rome start using new model of fountain in a given style? but in general I support this idea, just key seems wrong. Oct 11, 2022, 15:17 by tagging@openstreetmap.org: > Use model=* to describe fountains > >

Re: [Tagging] Feature Proposal - RFC - Historic

I see no value in approving de facto key. Maybe there would be value in deapproving historic=battlefield Also, is "are of historic interest" mismatches how historic=wayside_shrine historic=memorial many historic=wayside_cross are used. Oct 11, 2022, 15:15 by martianfreeloa...@posteo.net: >

Re: [Tagging] RFC - More sensible values for fountain=*

Le 11.10.22 à 11:23, Davidoskky via Tagging a écrit : On 11/10/22 10:22, Marc_marc wrote: you do not need to have the use of a key "approved for fountains" that would respect the meaning of the approved tag. however it would be useful to discuss/approve the most relevant values to describe the

[Tagging] offlist about for

Le 10.10.22 à 11:14, Davidoskky via Tagging a écrit : for=drinking/bottle/dog/... to describe how it can be used I'm quite unsure about this idea... a fountain that spouts water downwards can be used to fill bottles, to drink and to let dogs (and other animals?) drink.

[Tagging] advices about multiple values have inaccuracies , between several pages

Hello, I find that advices about multiple values have inaccuracies between several pages : https://wiki.openstreetmap.org/wiki/Any_tags_you_like#Syntactic_conventions_for_new_values Properties can have a large number of possible values my reading : key=yes/no value aren't a propertie, it's the

Re: [Tagging] advices about multiple values have inaccuracies , between several pages

Le 11.10.22 à 14:31, Mateusz Konieczny via Tagging a écrit : though https://taginfo.openstreetmap.org/keys/crossing%3Aisland is still a property To caricature your example: red=yes/no is a technically property this is not a good idea though, the hidden characteristic is color and the value is

[Tagging] Proposal - RFC - Use model to describe fountains

Use model=* to describe fountains https://wiki.openstreetmap.org/wiki/Use_Model_To_Describe_fountains_proposal Please discuss this proposal on its Wiki Talk page. ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] advices about multiple values have inaccuracies , between several pages

Oct 11, 2022, 14:44 by marc_m...@mailo.com: > Le 11.10.22 à 14:31, Mateusz Konieczny via Tagging a écrit : > >> though https://taginfo.openstreetmap.org/keys/crossing%3Aisland is still a >> property >> > > To caricature your example: > red=yes/no is a technically property > this is not a good

Re: [Tagging] Feature Proposal - RFC - Historic

On 11/10/2022 15:25, Mateusz Konieczny via Tagging wrote: Also, is "are of historic interest" mismatches how historic=wayside_shrine historic=memorial many historic=wayside_cross are used. Do you have a suggestion how to fix this? ___ Tagging

Re: [Tagging] Feature Proposal - RFC - Historic

Obviously, I support this. It has its own preset scheme in the iD editor, its own icons etc. The following are missing (of the top of my head, because I proposed them) from the list and were approved already: creamery ogham stone

Re: [Tagging] Feature Proposal - RFC - Historic

Thanks. I've just added ogham stone to the "already approved" list. On 11/10/2022 15:54, Anne-Karoline Distel wrote: Obviously, I support this. It has its own preset scheme in the iD editor, its own icons etc. The following are missing (of the top of my head, because I proposed them) from

Re: [Tagging] Feature Proposal - RFC - Historic

Oct 11, 2022, 15:39 by marc_m...@mailo.com: > Le 11.10.22 à 15:25, Mateusz Konieczny via Tagging a écrit : > >> I see no value in approving de facto key. >> >> Maybe there would be value in deapproving historic=battlefield >> >> Also, is "are of historic interest" mismatches how >>

[Tagging] offlist Re: RFC - More sensible values for fountain=*

Le 11.10.22 à 13:25, Davidoskky via Tagging a écrit : If I have a fountain that is not decorative, doesn't have a tap and doesn't provide drinking water, this fountain cannot be tagged. Because no main key applies to it. - Not a decorative fountain, thus not an amenity=fountain - Doesn't

[Tagging] Feature Proposal - RFC - Historic

Hello. I’m proposing to approve the historic=* key together with a number of tags: https://wiki.openstreetmap.org/wiki/Proposed_features/Historic historic=* is in widespread use and currently documented as de facto. Please comment wherever you feel most comfortable: - Here - On the wiki talk

Re: [Tagging] Feature Proposal - RFC - Historic

On 11/10/2022 14:54, Anne-Karoline Distel wrote: Obviously, I support this. It has its own preset scheme in the iD editor, its own icons etc. The following are missing (of the top of my head, because I proposed them) from the list and were approved already: creamery

Re: [Tagging] RFC - More sensible values for fountain=*

On 10/10/22 10:45, Marc_marc wrote: it's vague and overlap drinking at least Sorry, I didn't notice this and thus didn't reply to you before. I want this to be a more generic value than drinking: thus if you're unsure whether a fountain is a drinking fountain you can tag it as utility. If

Re: [Tagging] RFC - More sensible values for fountain=*

Oct 11, 2022, 09:48 by tagging@openstreetmap.org: >> Of course, this is not the key I'm actually proposing. I just don't want to >> get in another discussion about semantics and thus I would like to simply >> discuss the need of such a key without defining the actual name. >> >> If people

Re: [Tagging] RFC - More sensible values for fountain=*

sent from a phone > On 11 Oct 2022, at 12:06, Davidoskky wrote: > > I do agree, and that is also my objective; but I do like the idea of having a > very generic value you can fall back to when no other value applies. I don’t like the idea, because it will only slow down development of

Re: [Tagging] RFC - More sensible values for fountain=*

Of course, this is not the key I'm actually proposing. I just don't want to get in another discussion about semantics and thus I would like to simply discuss the need of such a key without defining the actual name. If people agree that such key is required I will then try to find,

Re: [Tagging] RFC - More sensible values for fountain=*

Am Di., 11. Okt. 2022 um 10:24 Uhr schrieb Mateusz Konieczny via Tagging < tagging@openstreetmap.org>: > > Is it possible that drinking fountain in a given style has multiple models? > absolutely yes. Cheers, Martin ___ Tagging mailing list

Re: [Tagging] RFC - More sensible values for fountain=*

sent from a phone > On 11 Oct 2022, at 11:30, Davidoskky via Tagging > wrote: > > Nobody is tagging the specific model type, such as distinguishing nasone from > the 1960s and nasone from the 1990s. > > Should we introduce another key for the style and then tag the specific model > of the

[Tagging] camp sites in Haiti

Hello, I noticed that many of the refugee camps in Haiti are tagged as tourism=camp_site which made me uneasy. Turns out there is the tag amenity=refugee_site. Would it be possible to re-tag those refugee camps in an automated edit? There are about 60 or 70 mapped. I'm not even sure if they all

Re: [Tagging] RFC - More sensible values for fountain=*

On 11/10/22 12:43, Martin Koppenhoefer wrote: or you simply don’t put this detail. This is problematic, since if you only tag amenity=fountain it will fall back to a decorative fountain since amenity=fountain appears to be defined in that way. I'll repeat the problems with the current

Re: [Tagging] RFC - More sensible values for fountain=*

Le 11.10.22 à 09:48, Davidoskky via Tagging a écrit : we just need to approve that it should be used for fountains as well. you do not need to have the use of a key "approved for fountains" that would respect the meaning of the approved tag. however it would be useful to discuss/approve the

Re: [Tagging] Feature Proposal - RFC - Water outlet

вт, 11 окт. 2022 г., 11:48 Martin Koppenhoefer : > On the other hand, if you are looking for places to do sports, it is not > sufficient to look at leisure=pitch if you want to find all of them. > Of course. Hierarchical tagging. leisure = pitch & sport = *. >

Re: [Tagging] RFC - More sensible values for fountain=*

On 11/10/22 10:22, Marc_marc wrote: you do not need to have the use of a key "approved for fountains" that would respect the meaning of the approved tag. however it would be useful to discuss/approve the most relevant values to describe the known cases We would need to approve that certain

Re: [Tagging] RFC - More sensible values for fountain=*

On 11/10/22 10:19, Martin Koppenhoefer wrote: this is not a redefinition, it is already like this. man_made=water_tap describes a water tap. man_made=water_tap is de facto being used to describe larger structures that contain a water tap. This wouldn't be a problem if there was a way to

Re: [Tagging] RFC - More sensible values for fountain=*

sent from a phone > On 11 Oct 2022, at 12:06, Davidoskky wrote: > > Some are indistinguishable from drinking fountains, some have drinking water > and can be used to wash clothes as well. all drinking fountains can be used to wash clothes, although it may not be legal in some instances,

Re: [Tagging] RFC - More sensible values for fountain=*

Le 11.10.22 à 12:27, Martin Koppenhoefer a écrit : When we tag a “model” it will sooner or later become a geek tag which would indeed distinguish a 60ies from a 90ies nasone :D model=nasone as a 1st step if ppl want, model=nasone_1960 or model=nasone:1960 or :date isn't an issue

Re: [Tagging] Feature Proposal - RFC - Water outlet

Am Mo., 10. Okt. 2022 um 17:33 Uhr schrieb Illia Marchenko < illiamarchenk...@gmail.com>: > Unification of tags allows more simple usage source data, e.g leisure = > pitch allows rendering of all pitches, but lots of tags as > leisure=tennis_court, leisure = baseball_playground, leisure = >

Re: [Tagging] RFC - More sensible values for fountain=*

Le 11.10.22 à 10:19, Martin Koppenhoefer a écrit : Am Mo., 10. Okt. 2022 um 09:53 Uhr schrieb Davidoskky : I would propose the deprecation of the value fountain=stone_block since it could be tagged as fountain=driking, material=stone. There are many fountains made of stone, but not

Re: [Tagging] Feature Proposal - RFC - Historic

As I mentioned on the community forum, the historic=* key is full of tags that should really need to be revisited, changed or redefined before they can be voted on. I strongly advise against approving all historic=* tags en masse. Elaboration on the community forum:

Re: [Tagging] Feature Proposal - RFC - Historic

I've reduced the proposal to the historic=* key itself. No values included anymore. On 11/10/2022 17:03, Marc_marc wrote: Le 11.10.22 à 16:01, Peter Neale via Tagging a écrit : Many ruins and memorials are "of historic interest" it is true, but that could be tagged as a property

Re: [Tagging] Feature Proposal - RFC - Historic

Yeah, sorry. I'm doing this out of courtesy for B-unicycling. They had started the Crannog proposal: https://wiki.openstreetmap.org/wiki/Proposed_features/crannog Nobody commented during RFC and then everybody voted against; which is not nice. I was one of them. I'm happy to hand over the

Re: [Tagging] camp sites in Haiti

> Would it be possible to re-tag those refugee camps in an automated edit? … I'm not even sure if they all still exist 12 years later. It would not be possible, because we do not know if they still exist. However a local mapper or someone who has visited the area could re-tag them, after

Re: [Tagging] Feature Proposal - RFC - Historic

Le 11.10.22 à 16:16, Mateusz Konieczny via Tagging a écrit : do not attempt to have nice definition for all keys https://wiki.openstreetmap.org/wiki/Counterintuitive_keys_and_values I find the advice very strange on the contrary let's try to have a nice definition for all keys and not

Re: [Tagging] Feature Proposal - RFC - Historic

Keeping the status as de facto, avoids confusion about approval status of the values. I think it's best to pick another battle. Peter Elderson > Op 11 okt. 2022 om 17:14 heeft martianfreeloader > het volgende geschreven: > > I've reduced the proposal to the historic=* key itself. No values

Re: [Tagging] Feature Proposal - RFC - Historic

I appreciate the effort here, but I think it's too broad. I would rather have a more focused look at individual keys that considers what the tagging alternatives are to each, and to assess whether there is duplication and/or debates surrounding them that are worth investigating. There is really

Re: [Tagging] Feature Proposal - RFC - Historic

Le 11.10.22 à 16:01, Peter Neale via Tagging a écrit : Many ruins and memorials are "of historic interest" it is true, but that could be tagged as a property ("historic=yes") of the object "man_made=" . witch main tag for aa ruins with historic interest ? it's not a building=* anymore and

Re: [Tagging] Feature Proposal - RFC - Historic

I would propose that it might be a good idea to reduce the number of inflight proposals per person to one. As it is there is a flood of proposals that only the most diehard tagging proposal commenters can and will take the time to look at and consider with all the negative consequences that

Re: [Tagging] Feature Proposal - RFC - Historic

Oct 11, 2022, 17:05 by marc_m...@mailo.com: > Le 11.10.22 à 16:16, Mateusz Konieczny via Tagging a écrit : > >> do not attempt to have nice definition for all keys >> > https://wiki.openstreetmap.org/wiki/Counterintuitive_keys_and_values > > I find the advice very strange > on the contrary

Re: [Tagging] Lyft and nameless sectioning in OSM

I agree with Mateusz. * landuse=retail,residential,industrial, etc. are not bound to the North American concept of zoning. * landuse=retail does correctly not encompass the veterinarian, because a vet mostly sells services, not goods. It is thus correct that the vet is in a

Re: [Tagging] Lyft and nameless sectioning in OSM

That they exist isn't the question. I acknowledged this. It doesn't make sense why they should. The reason farmland exists is, * The presence of land alone is not mappable, IE., farmland unlike Commercial and Retail Zones can not be inferred by buildings. * Farmland gives you the ability to add

Re: [Tagging] Lyft and nameless sectioning in OSM

On 11/10/2022 19:34, Evan Carroll wrote: Some examples of these nameless sections are, * w1101484647 by A_Prokopova_lyft That was added in https://www.openstreetmap.org/changeset/127101982 , which was that user's first edit in OSM. I'd suggest asking them in the changeset about that edit,

Re: [Tagging] Lyft and nameless sectioning in OSM

For the purposes of steering the convo, I think a better question as it relates to this list is the more general: * If there is one Commercial Building in an unnamed Commercial Zone: what value is there for a user? * If there are two Commercial Buildings in an unnamed Commercial Zone: what value

Re: [Tagging] Lyft and nameless sectioning in OSM

On Tue, Oct 11, 2022 at 12:05 PM Evan Carroll wrote: > > For all of these cases, when "Zone" isn't established by law I see no > value. I think this would be a good place to start. But I'm also interested > in knowing Lyft's motivations behinds these Zones and I assume they're on > the list or

Re: [Tagging] Lyft and nameless sectioning in OSM

On Tue, Oct 11, 2022 at 2:17 PM Mateusz Konieczny via Tagging < tagging@openstreetmap.org> wrote: > > Oct 11, 2022, 20:34 by m...@evancarroll.com: > > these polygons don't add any value: they're not describing what things > are, and they're frequently incorrect > > You mentioned

Re: [Tagging] Lyft and nameless sectioning in OSM

Oct 11, 2022, 21:42 by m...@evancarroll.com: > I just don't see the value even if everything was done right. > That is simply utterly irrelevant. Even if you do not see value of mapping area:highway=* or shops or detail of individual trees or opening hours or bicycle parkings or landuse or

Re: [Tagging] Feature Proposal - Voting - Payment denominations

On Sun, 9 Oct 2022 17:08:46 -0700 stevea wrote: > At least in the USA, using currency (required to be accepted) isn't > like barter (doesn't have to be accepted): we even have a notation > on each and every "Federal Reserve Note" (the debt instruments used > in the USA as paper currency, often

Re: [Tagging] Feature Proposal - RFC - pickup

> > While building=carport would combine well with > amenity=pickup_point,that obviously doesn't work with amenity=parking. I guess the reserved parking spots could be mapped as an area tagged > with amenity=pickup_point on top of a larger area tagged with > amenity=parking. How does that sound?

Re: [Tagging] Lyft and nameless sectioning in OSM

Oct 11, 2022, 21:28 by cliff...@snowandsnow.us: > As Andy suggested, contact the mapper with your concerns. I've have had good > luck dealing with Lyft in the past and appreciate their edits in my area. > Though note that it appears that this Lyft mapping is 100% fine and done as expected. I

[Tagging] Lyft and nameless sectioning in OSM

Lyft has been adding thousands of Polygons around Houston for Retail and Residential and Industrial Areas. I'm just wondering what the motivation here is for Lyft's behavior, especially in Texas. It seems like a lot of bloat on OSM. IMHO, these polygons don't add any value: they're not describing

Re: [Tagging] Lyft and nameless sectioning in OSM

Oct 11, 2022, 20:34 by m...@evancarroll.com: > these polygons don't add any value: they're not describing  what things are, > and they're frequently incorrect > You mentioned https://www.openstreetmap.org/way/1101484647 Why it is supposed to be wrong? Are there additional objects not mapped in

Re: [Tagging] Feature Proposal - Voting - Payment denominations

Right. According to the Federal Reserve: https://www.federalreserve.gov/faqs/currency_12772.htm "Is it legal for a business in the United States to refuse cash as a form of payment? "There is no federal statute mandating that a private business, a person, or an organization must accept currency

Re: [Tagging] Lyft and nameless sectioning in OSM

> > > I disagree. People may not always agree about the relative usefulness of > some types of data, but someone advocating for some data to be added to > OSM should really be able to explain why they find it useful. > > That's all I plan to say on this side remark because it's not really >

Re: [Tagging] Feature Proposal - RFC - pickup

Le 11.10.22 à 21:33, Evan Carroll a écrit : We could map these onto the building polygon explicitly please : one element = one object building <> the user of the building. so imho it's best to have one object for the buildinng, another for the shop or the pickup or whatever. ex of issue : name

Re: [Tagging] Lyft and nameless sectioning in OSM

Re: "not to convey (additional) information" No, it is useful information. A human who knows the local area can pretty easily determine which blocks or streets are retail or industrial. This can be done even if you do not know the exact names of the buildings or businesses - sometimes in an

Re: [Tagging] Feature Proposal - Voting - Payment denominations

On Tue, 11 Oct 2022, 09:16 Martin Koppenhoefer, wrote: > in Italy, one and two cent coins have been abolished, they are not > accepted any more in shops, and while prices are still ending mostly with > 9, the sum gets rounded. > OT for this discussion: Where I live in Italy, one and two €cent

Re: [Tagging] Lyft and nameless sectioning in OSM

" when there is no key on the zone what does the zone convey?" It conveys that the area of land is primarily used for selling goods (landuse=retail). This is useful because retail areas, which include shops and restaurants, are high-traffic destinations, which many map users will be interested

Re: [Tagging] Lyft and nameless sectioning in OSM

> > I just don't see the value even if everything was done right. > > That is simply utterly irrelevant. Even if you do not see value of mapping > area:highway=* or shops or detail of individual trees or opening hours > or bicycle parkings or landuse or glaciers or anything else, then it is >

Re: [Tagging] Lyft and nameless sectioning in OSM

Oct 11, 2022, 22:12 by m...@evancarroll.com: >>> I just don't see the value even if everything was done right. >>> >> That is simply utterly irrelevant. Even if you do not see value of mapping >> area:highway=* or shops or detail of individual trees or opening hours >> or bicycle parkings or

Re: [Tagging] Lyft and nameless sectioning in OSM

On 11.10.22 21:51 Mateusz Konieczny wrote: Oct 11, 2022, 21:42 by m...@evancarroll.com: I just don't see the value even if everything was done right. That is simply utterly irrelevant. I disagree. People may not always agree about the relative usefulness of some types of data, but

Re: [Tagging] Lyft and nameless sectioning in OSM

sent from a phone > On 11 Oct 2022, at 21:45, Evan Carroll wrote: > > No value. There is no reason to call neighboring w1101484649 "Commercial > Zone". Why is a car wash and a vet commercial, and the gas station is retail? this seems completely in line with what I would expect for

Re: [Tagging] Lyft and nameless sectioning in OSM

sent from a phone > On 11 Oct 2022, at 21:45, Evan Carroll wrote: > > If there is no name, what is the value? it is a property that helps understanding how an area is structured. If there is a name you should use “place” Cheers Martin ___

Re: [Tagging] Lyft and nameless sectioning in OSM

Thanks Joseph Eisenberg! That's exactly what I'm looking for. Good answer. So basically the primary use case of an **unnamed** residential, commercial, industrial, and retail "Zones" is not to convey (additional) information but to serve as a good-enough styling solution about what the zone

Re: [Tagging] RFC - More sensible values for fountain=*

Vào lúc 01:22 2022-10-11, Marc_marc đã viết: the namespace isn't needed, it's just a bad pratice due to a missing feature in iD (another editor uses taginfo combinations to propose the most relevant values, iD on the other hand proposes everything often without filter, but as I said, it is not

Re: [Tagging] Lyft and nameless sectioning in OSM

> > > In a retail area, if every shop is mapped precisely then the > landuse=retail tag could possibly be inferred, in the same way that Google > maps "area of interest" - but looking at Google you can often see mistakes > due to missing or miscategorized shops and homes. Adding the > landuse