Re: [Tagging] Please join the OSM accessibility initiative

I'm a bit surprised that you make no reference to the long list of past and current projects that address accessibility issues, including vision. I would suggest reading up on those activities first before launching head first into something that just might repeat the mistakes of the past.

Re: [Tagging] [RFC] Feature Proposal - free period products

Am 23.08.2023 um 10:41 schrieb Anne- Karoline Distel: Fair points. Transgender people are also one of the reasons why I didn't want to use the terminology "feminine hygiene". There's a thread somewhere (in the lead up to defining the IMHO perfectly fine current tagging), that goes in to the

Re: [Tagging] What separator do you use for multiple value

Am 14.06.2023 um 11:26 schrieb Martin Koppenhoefer: ...for housenumbers periods are an alternative to semicolons. You probably wanted to write "commas", periods are not in use as separators for house numbers. See

Re: [Tagging] Help with new tags about wheelchair

Am 07.05.2023 um 21:56 schrieb ro...@onwheelsapp.com: We have been in contact with Wheelmap. They are using the tag wheelchair=yes/no, but with On Wheels we have a different approach. We measure objective data about the entrance and toilet of a building. Who did you talk to at

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] Literal translation of street names

https://wiki.openstreetmap.org/wiki/Names#Language-specific_names Am 19.09.2022 um 12:36 schrieb Janko Mihelić: A user in my city (Zagreb) started translating street names into English, and I don't know what to do about it. An example of translation is Butcher Street for Mesnička ulica, or

Re: [Tagging] addr:floor and level:ref - Wiki review welcomed

addr:floor is an address tag and used in -(postal)-addresses- when the floor is customarily or required to be included. level:ref is a SIT tag used to indicate the name (or other numbering) of a level contrary to the zero based number of the level tag. While both level:ref and addr:floor can

Re: [Tagging] addr:floor and level:ref - Wiki review welcomed

This doesn't make any sense outside of trying breaking the SIT tagging scheme If you have changes to suggest do that in the context of  an SIT improvement and not just so that you can add yet another SC challenge. Am 18.12.2020 um 13:11 schrieb Mateusz Konieczny via Tagging: I heavily edited

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

Am 22.11.2020 um 17:35 schrieb Brian M. Sperlongano: .. I like the idea of an api limit, though we would need a strategy to deal with existing large objects. .. This is, "surprise", not a new topic. There are certain issues with the semantics of relations which make this slightly more

Re: [Tagging] Feature Proposal - RFC - Rideshare Access

020-11-04 at 07:26 +1100, Andrew Harvey wrote: On Tue, 3 Nov 2020 at 23:14, Simon Poole mailto:si...@poole.ch>> wrote: We don't seem to have a tagging currently for dedicated pickup locations in this kind of context, bus stops etc are naturally taggable), if considered

Re: [Tagging] Feature Proposal - RFC - Rideshare Access

and other transportation hubs; without that "big picture", merely focusing very narrowly on the access attribute feels incomplete. On Sat, Oct 31, 2020 at 4:03 PM Simon Poole <mailto:si...@poole.ch>> wrote: I think there is a bit of a misunderstanding here. This is no

Re: [Tagging] Feature Proposal - RFC - Rideshare Access

e information someone traveling through the airport looking for ground transportation would want to know is: 1. Is it a ride share (pre-arranged pickup) or taxi stand (on-demand pickup) 2. Is it limited to only specific ride share companies? 3. Is it pickup only, dropoff only, or both? On Sat, Oct 31

Re: [Tagging] Feature Proposal - RFC - Rideshare Access

Am 31.10.2020 um 16:11 schrieb Philip Barnes: ... Also private hire, which need to be booked in advance and have the same access rights/restrictions on the public highway as a private car. For some reason I cannot fathom, in London private hire are called minicabs. Uber and Lyft are

Re: [Tagging] Feature Proposal - RFC - Rideshare Access

For starters I would oppose using the term "rideshare" for what is a taxi/chauffeur service. It should be noted that there are actual rideshare organisations and services out there, but uber, grab, lyft etc. are not among them, they are simply trying to co-opt a term with positive associations

Re: [Tagging] [OSM-talk] Face and license blurring (GDPR territories)

Am 07.10.2020 um 11:46 schrieb Niels Elgaard Larsen: ... They stopped it for a while.  Then they put it back in. Now (checked today) under edit there is a  "edit privacy blurs" there is still a "Download unprocessed originals" option. The "Download unprocessed originals" returns blurred

Re: [Tagging] We should stop using hyphens to denote address ranges

Am 19.08.2020 um 10:46 schrieb Sarah Hoffmann: > ... > We'd also need a new tag to indicate the interpolation steps odd/even/all. > It's not really > a good idea to reuse addr:interpolation because on a building outline it > becomes ambigious: > you'd have to check for the presence of other

Re: [Tagging] We should stop using hyphens to denote address ranges

The correct ways to model a range of house numbers is to use an address interpolation or explicitly list the numbers (using comma or semi-colons as delimitiers), anything else is woefully underspecified, not to mention other issues, for example hyphens being used to delimit building and

Re: [Tagging] Apparent conflicting/redundant access tags

This is why access=yes is useless on highway objects as it is not clear if it overrides implicit access restrictions or not. If it did it would have to be accompanied by a comprehensive list of forbidden access modes (and similar arguments apply to all but the simplest use of access=no too).

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

Am 25.07.2020 um 03:45 schrieb Jarek Piórkowski: > > Well, a new API endpoint _could_ automatically read through the entire > history of a node and note which tags changed when. It would > essentially be doing what I do when I open the node history in JOSM > and look when tags changed - only

Re: [Tagging] amenity=customer_service RFC

Wouldn't most, if not all, cases where this would be used already be covered by the corresponding (and likely already in use) shop=* value? Am 23.07.2020 um 12:49 schrieb Mateusz Konieczny via Tagging: > See https://wiki.openstreetmap.org/wiki/Proposed_features/Customer_service > > Feedback,

Re: [Tagging] QA Tag for addr:city vs al8/al9 boundary

IMHO addr:city is the "postal" city at least for countries that have such a concept. With other words validating the tag against admin boundaries is fundamentally flawed to start with and will only work in the cases in which admin entity and postal city just happen to have the same name (in the

Re: [Tagging] Access tag abuse examples

Am 25.05.2020 um 01:48 schrieb Mateusz Konieczny via Tagging: > .. > (1) there is some seemingly good overcomplicated tagging access=yes > (2) there is a good and simpler replacement > > ___ > Tagging mailing list > Tagging@openstreetmap.org >

Re: [Tagging] Permanent ID/URI --- off topic email

ways, which I am only starting to look to consider, maybe I could > look for objects with a similar geometric center for the replacement > object.  > > Best regards, > > Stuart  > > > On Tue, 19 May 2020 at 11:41, Simon Poole <mailto:si...@poole.ch>> wrote: &

Re: [Tagging] Permanent ID/URI --- off topic email

It should be noted that (for Nodes) id + version is actually stable (Ways and Relations are more complicated). So if you have id + version, you can - check that it is the current version of the object (all fine and dandy) - check if there is a later (undeleted) version, check if it (depending

Re: [Tagging] RFC ele:regional

cated on things without knowing exactly which datum is being used" or do we use ele for that. Simon Am 08.05.2020 um 03:11 schrieb Greg Troxel: > Simon Poole writes: > >> Am 04.05.2020 um 15:19 schrieb Kevin Kenny: >>> Elevation as height-above-ellipsoid, unless you're u

Re: [Tagging] RFC ele:regional

Am 04.05.2020 um 15:19 schrieb Kevin Kenny: > Elevation as height-above-ellipsoid, unless you're using it in the > intermediate results of a GPS calculation, is nonsensical. However if you read the argumentation on the Altitude page that was exactly the reasoning: store hae and therefore be able

Re: [Tagging] RFC ele:regional

Mai 2020 um 10:50 Uhr schrieb Simon Poole <mailto:si...@poole.ch>>: > > 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 20

Re: [Tagging] RFC ele:regional

Just so that it is clear for everybody what the issue is about,  Android is not really relevant outside of resurfacing it. 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

Re: [Tagging] Definition and usage of Key:mtb:scale:imba?

IMHO, the problem is using mtb:scale:imba in place of mtb:scale for normal trails which I suspect the intent of the original wording was to avoid that happening. Simon Am 22.04.2020 um 10:53 schrieb Andrew Harvey: > I've been using

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

It doesn't really matter if I think the current mixup of use-based vs. style building values is particular useful or not, I still need to be able to display (and suggest) them in a meaningful way. Am 07.04.2020 um 15:13 schrieb Marc M.: > Le 07.04.20 à 12:19, Simon Poole a écrit : >> is

[Tagging] building=public vs. building=civic

While doing my regular comparison of different sets of presets (see my talk at SotM Milano for more information), one of the more noticeable differences  is the the presets that I maintain, and by extension JOSM, does not include building=civic. This was introduced later than building=public and

Re: [Tagging] Which languages are admissible for name:xx tags?

I think we are in violent agreement. Am 27.03.2020 um 14:04 schrieb Paul Allen: > On Fri, 27 Mar 2020 at 12:31, Simon Poole <mailto:si...@poole.ch>> wrote: > > The point is that the name in question isn't actually the name in > de-CH, it's the Swedish name. > >

Re: [Tagging] Which languages are admissible for name:xx tags?

The point is that the name in question isn't actually the name in de-CH, it's the Swedish name. The general norm all over the world is that most places -don't- have names in languages that are not used locally. Pretending that they do isn't a useful concept and yes they typically won't have

Re: [Tagging] Which languages are admissible for name:xx tags?

me. > > The idea in these cases is the we get rid of all other name tags that > can be stored and curated better in WD. > > On March 25, 2020 10:48:45 PM GMT+01:00, Simon Poole > wrote: > > Note that lots of the wikidata names are nonsense and are simpl

Re: [Tagging] Which languages are admissible for name:xx tags?

Note that lots of the wikidata names are nonsense and are simply derived from the wikipedia page name (which a wp page has to have, but it doesn't imply that the object actually has a name in the language of the wikipedia you are looking at). For example the municipality I live in has a German and

Re: [Tagging] Deleting template parameters copied to data items

Yes I was just going to point out that https://taginfo.openstreetmap.org/taginfo/apidoc#api_4_key_wiki_pages wouldn't return the combination info if removed from the page. That doesn't mean that we can't change the wiki, but it needs to be a coordinated effort that includes adapting the most

Re: [Tagging] Tagging Free Water for cafés, bars, restaurant

Am 13.01.2020 um 21:23 schrieb European Water Project: > > > Thanks Hauke > > The namespace scheme could work. It is very elegant and clean. The > meaning of customer in container is a bit confusing... as it can be a > paying or non paying customer.  > > I could see :  > free_water = >

Re: [Tagging] Rare route values route=inline_skates and route=running

While the number is "low" some of them are quite long https://wiki.openstreetmap.org/wiki/Switzerland/InlineNetwork Simon Am 11.01.2020 um 06:21 schrieb Joseph Eisenberg: > The tag route=inline_skates was added to Map features, but it has > only been added a few times in the past 4 years. > >

Re: [Tagging] addresses on buildings

Am 06.01.2020 um 22:55 schrieb Volker Schmidt: > > > > > This depends on the country. > > It is "forbidden" to put the address on the building in Denmark, > > A similar rule exist in Italy: the number has to be put where the > actual entrance is, as the number identifies an entrance and

Re: [Tagging] Tagging of bicycle anti-features

I would suggest adding a suitable "hazard" tag to the end of the cycleway (probably the last node before the common node with the road). Rationale: you probably want to maintain connectivity to the road because in the worst case it would still be possible to get to the road, on the other hand you

Re: [Tagging] amenity=hospital on things that are not hospitals - is it a good idea?

Am 28.10.2019 um 11:11 schrieb marc marc: > Le 28.10.19 à 09:44, Mateusz Konieczny a écrit : >> "sign having a hospital icon and no name can simply be tagged >> type=destination_sign + amenity=hospital" >> https://wiki.openstreetmap.org/wiki/Relation:destination_sign > Yes it's horrible > > the

Re: [Tagging] amenity=hospital on things that are not hospitals - is it a good idea?

There are some other "weird" things, for example using "intersection" instead of "via" for the via role, which means that the handling needs to be special cased relative to turn restrictions and similar relations. Am 28.10.2019 um 15:51 schrieb Tom Pfeifer: type=destination_sign +

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

OpenStreetMap is a project that produces open data. "open" implies everybody being allowed to use the data in any way they see fit, including rendering disused facilities in green with pink stripes. There is nothing "sad" about that. Am 26.09.2019 um 15:16 schrieb Paul Allen: > On Thu, 26 Sep

Re: [Tagging] Feature Proposal - Voting - Campsite properties

Am 18.09.2019 um 09:37 schrieb Martin Koppenhoefer: > > sent from a phone > >> On 18. Sep 2019, at 09:22, Simon Poole wrote: >> >> My point was more that you should ignore the shop classification and >> assume that that this is simply facility that in some f

Re: [Tagging] Feature Proposal - Voting - Campsite properties

Am 17.09.2019 um 08:29 schrieb Joseph Eisenberg: > I didn't think shop=laundry would work for a laundry room at a campsite. > My point was more that you should ignore the shop classification and assume that that this is simply facility that in some form provides access to clothes washing machines

Re: [Tagging] Feature Proposal - Voting - Campsite properties

Do you actually believe that it is a good idea to have people map individual washing machines  and dryers (the tag exists for washing_machine but is super low use)? I can see the need to map laundries (and that might have slightly wider application than just camp sites), so why not shop=laundry

Re: [Tagging] Feature Proposal - RFC - appointment

Am 10.09.2019 um 10:00 schrieb Martin Koppenhoefer: > > > sent from a phone > > On 8. Sep 2019, at 22:11, Simon Poole <mailto:si...@poole.ch>> wrote: > >> Isn't this semantically in the end not the same as "unknown" (as in any >> application w

Re: [Tagging] Feature Proposal - RFC - appointment

Isn't this semantically in the end not the same as "unknown" (as in any application would have to equate this to  "you have to inquire if it is open")? Am 08.09.2019 um 17:10 schrieb Ruben: > Proposal for opening_hours syntax element "appointment", similar to "open" > and "off": > >

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

Was going to ask the same thing, not that I don't think that both are redundant, but why have two -different- redundant tags? Am 05.09.2019 um 18:46 schrieb Leif Rasmussen: > How is this different from highway=corridor?   > > On Thu, Sep 5, 2019, 12:42 PM Jeremiah Rose >

Re: [Tagging] Fwd: Walking & Cycling Node Network tagging: undoing the hijacking of rcn and rwn

Am 04.09.2019 um 15:59 schrieb Peter Elderson: > Thanks for the illustrations! > > network=* gives geographical scope (local, regional, national, > international) and transport mode (bicycle, foot, canoe, horse, mtb, > ski, skate, ) You know what I'm going to point out. The redundant coding

Re: [Tagging] me fail english? | Re: craft=sculpter <> craft=sculptor

See https://github.com/openstreetmap/iD/pull/4504 Aka old, fixed issue. Am 30.08.2019 um 16:02 schrieb Martin Koppenhoefer: > > > Am Fr., 30. Aug. 2019 um 14:25 Uhr schrieb Rory McCann > mailto:r...@technomancy.org>>: > > I think it's just a misspelling. I'm a native english speaker and >

Re: [Tagging] Multiple tags for one purpose

Am 24.08.2019 um 21:03 schrieb Valor Naram: > > Editors won't (in general) implement tags in presets unless they're > widely used.  Unless editors and carto support tags, they won't get > widely used, so editors and carto won't support them.  Chicken and egg. > > Yes, you're right. But I was the

Re: [Tagging] Feature Proposal - Voting - Tag:staff_count:nurses & doctors

That should likely be FTEs (full time equivalents), not that I believe this is something that should actually be in OSM (what about wikidata?). Am 02.08.2019 um 08:08 schrieb Rory McCann: > On 01/08/2019 22:17, Mhairi O'Hara wrote: >> Voting is now open for the proposed feature staff_count:nurses

Re: [Tagging] Subkeys like payment:*=yes/no? | Re: Country code value prefix? | Re: Feature Proposal - Voting - Tag:insurance:health

Am 02.08.2019 um 09:26 schrieb Rory McCann: > On 02/08/2019 08:42, Warin wrote: >> It is possibly that some will only accept certain insurance firms and >> reject others. I am thinking of insurance firms that run some medical >> facilities. > > We use subkeys for payment types

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

Am 29.07.2019 um 10:44 schrieb Martin Koppenhoefer: > > sent from a phone > >> On 29. Jul 2019, at 08:13, Joseph Eisenberg >> wrote: >> >> Someone needs to check how denotation=cluster is >> actually used now days. > > this tag was introduced through an automated edit many years ago with the >

Re: [Tagging] Feature Proposal - RFC - health_amenity:type

Am 26.07.2019 um 02:19 schrieb Joseph Eisenberg: > There are still 2  problems with healthcare:equipment: > > 1) Healthcare:equipment is yet another new feature key for database > users to support, if tagged on its own node at the location of the > MRI. This requires Osm20gsql users like the main

Re: [Tagging] Maxweight wiki page changes

Could both of you be a bit more transparent about the situation. You should be disclosing that Mateusz is being paid to work on your project and while not a direct employer-employee relationship, it is clearly that the success of what Mateusz is working on is in the end dependent on you accepting

Re: [Tagging] My ban by user Woodpeck = Frederik Ramm

Besides being off-topic here, 99.9% of the background is missing. Perma-bans for contributors in OSM are extremely rare and definitely not imposed lightly, just as they are not in this case: see https://www.openstreetmap.org/user/ulamm/blocks for just a tiny bit of the very long story behind this.

Re: [Tagging] Which global OSM mailing list for the "community index"?

The idea of providing a matrix (or mattermost or ...)  instance for the OSM community has been floating around for a long time, but on the one hand it would require somebody willing to to the sysadmin work for it, and somebody would need to do some work on integrating OSM authentication (as I side

Re: [Tagging] A modest proposal to increase the usefulness of the tagging list

unnecessary noise, most of it caused by less > than a handful of people. > > Overall, I don't think there is any issue here that needs to be urgently > addressed. > >> -----Original Message- >> From: Simon Poole >> Sent: Sunday, 2 June 2019 18:48 >>

Re: [Tagging] A modest proposal to increase the usefulness of the tagging list

Am 02.06.2019 um 15:41 schrieb Paul Allen: > On Sun, 2 Jun 2019 at 14:17, Simon Poole <mailto:si...@poole.ch>> wrote: > > Am 02.06.2019 um 14:40 schrieb Paul Allen: >> >> As I already said, I understand your frustration.  > > No, obviously you don

Re: [Tagging] A modest proposal to increase the usefulness of the tagging list

Am 02.06.2019 um 14:40 schrieb Paul Allen: > On Sun, 2 Jun 2019 at 09:49, Simon Poole <mailto:si...@poole.ch>> wrote: > > > In the interest of keeping the list at least half usable, I would > suggest that we all, starting now, voluntarily submit to: > >

Re: [Tagging] A modest proposal to increase the usefulness of the tagging list

elp >with >this (I'm not proposing to write one or figure what could be used for >doing >so). But what if the 4 proposals are reached? Or someone feels the need >to >post 40 comments during a month? How do we stop the flood? > >Polyglot > >On Sun, Jun 2, 2019 at 10:49 AM Sim

[Tagging] A modest proposal to increase the usefulness of the tagging list

As a reader of this list I'm slightly overwhelmed by it right now. Besides the longish off topic discussions that should have been held somewhere else, we've had a massive increase in the number of proposals and comments on these. As these typically will require looking at the proposal,

Re: [Tagging] Underground Mall entrances?

Am 02.06.2019 um 07:37 schrieb Joseph Eisenberg: > Underground malls are often mapped with location=underground and > layer=-1 and more negative values can be used for the underground > levels of features within the mall. layer is a rendering hint and only indicates the position relative to over

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

king (as is the case with the specific example outside of rushhours iirc) then the legal semantics are the same as if there are no lights. >   > >   > > *From:*Simon Poole > *Sent:* Saturday, 25 May 2019 20:25 > *To:* tagging@openstreetmap.org > *Subject:* Re: [Tagging] Non-orthog

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

Am 25.05.2019 um 02:18 schrieb Paul Allen: > > +1 for "mutually exclusive."  Except, perhaps, in Poland.  I'm still > waiting for an answer on that one. > > Traffic signal controlled crossings with markings (including stripes of some colour) exist (not claiming that they are "common") at least

Re: [Tagging] solving iD conflict

Am 24.05.2019 um 19:37 schrieb Kevin Kenny: > On Fri, May 24, 2019 at 10:18 AM Christoph Hormann wrote: >> On Friday 24 May 2019, Kevin Kenny wrote: >>> Unless you intend to produce further evidence (to which I would >>> listen), I consider the insinuation that the iD developers have a >>>

Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

Am 24.05.2019 um 00:59 schrieb Nick Bolten: > > The talk ML might be a better spot for this, this topic has already > strayed quite far from the original topic. (And maybe start the topic > on a more positive prospect instead of with a rant ;-) > > So far as I can tell, the topic on this mailing

Re: [Tagging] Wiki changes for police tag

ou will find that most people will disagree with and will want to tag buildings as buildings.  In any case the answer to my question seems to be "sorry we didn't think of that". > > Best, Jan > > Am 18. Mai 2019 10:36:32 MESZ schrieb Simon Poole : > > Seems as if the

Re: [Tagging] Opening hours syntax for non Gregorian calendar

Am 18.05.2019 um 15:28 schrieb Paul Allen: > ... > Can we just ignore the problem?  For Easter, maybe.  Data consumers > could build in > country-specific rules defining if Easter is Orthodox or Catholic.  > Along with astronomical > calculations, that would allow an app to say "This office in a

Re: [Tagging] Opening hours syntax for non Gregorian calendar

As I've pointed out before the one thing that is unproblematic to add are more variable date public holidays, right now there is only easter defined,  adding ramadan for example would be no problem. Further expressing a rule is one thing, evaluating it is a something else, and adding some kind

Re: [Tagging] Wiki changes for police tag

Seems as if the proposal and now the definite wiki page is missing one, not quite unimportant, bit of information: is police an attribute to be used on other "top-level" (say for example building=xx OSM objects or does it define a stand alone "top-level" object itself? Simon Am 17.05.2019 um

Re: [Tagging] RFC - Connectivity

Be prepared for everybody to jump on you, because: https://wiki.openstreetmap.org/wiki/Proposed_features/transit Am 22.04.2019 um 17:55 schrieb Leif Rasmussen: > Hi everyone! > I have recently been mapping a lot of turn:lanes information on > highways in my area, but ran into the issue that

Re: [Tagging] Expand the key:opening_hours

Am 14.03.2019 um 23:18 schrieb Phake Nick: > > > 在 2019年3月14日週四 20:38，Simon Poole <mailto:si...@poole.ch>> 寫道： > > Some more comments: > > - the OH values are currently always evaluated in the local time zone > (or to go even a bit further i

Re: [Tagging] Expand the key:opening_hours

t; Warin <61sundow...@gmail.com> 於 2019年3月14日週四 上午8:29寫道： >> On 14/03/19 10:52, Simon Poole wrote: >>> Just a PS: any grammar extension need to be compatible with the use of >>> OH strings in conditional restrictions too, see >>> https://wiki.openstreetm

Re: [Tagging] Expand the key:opening_hours

14.03.2019 um 00:38 schrieb Simon Poole: > The basic problem with proposing an extension to the current OH grammar > is that it is already far too complicated and full of ambiguities, there > are afaik currently only two parsers that handle > 90% of the grammar > and most of the other

Re: [Tagging] Expand the key:opening_hours

The basic problem with proposing an extension to the current OH grammar is that it is already far too complicated and full of ambiguities, there are afaik currently only two parsers that handle > 90% of the grammar and most of the other ones are rather broken, adding more stuff is definitely not

Re: [Tagging] Micronations

May I point out that this discussion is patently silly? The user in question has already been blocked and at least their initial changesets were reverted 2 months ago. Naturally any remaining fictional edits should be reverted too and the user reported again to tho DWG. Am 9. Februar 2019

Re: [Tagging] The actual use of the level tag

See the original page on the Karlsruher schema: https://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema Am 23.01.2019 um 05:04 schrieb Eugene Alvin Villar: > On Mon, Jan 21, 2019 at 4:11 PM Simon Poole <mailto:si...@poole.ch>> wrote: > >

Re: [Tagging] The actual use of the level tag

As tordanik has already pointed out the main issue with the proposals is that there is no inherent ordering that can be deduced from level values on objects if they are not (integer) numbers, so any such scheme requires far more insight, effort and available context from joe-casual-mapper and

Re: [Tagging] service

in the wild and it turning up in the preset. Simon Am 08.01.2019 um 15:50 schrieb Bryan Housel: >> On Jan 8, 2019, at 2:30 AM, Simon Poole wrote: >> >> Am 07.01.2019 um 16:12 schrieb Bryan Housel: >>> ... >>> On “both is OK”. the `service:vehicle` issue was be

Re: [Tagging] Facts and opinions

Am 08.01.2019 um 23:55 schrieb Martin Koppenhoefer: > ... > With current tools there is no tag completion for the individual > values in lists, while the alternative already works. > Value completion has for lists has woked since ages in Vespucci (you normally would use the form interface where

Re: [Tagging] How do you say "no" with semicolon'ed lists? Re: Facts and opinions

Am 08.01.2019 um 16:25 schrieb Rory McCann: > On 08/01/2019 08:30, Simon Poole wrote: >> and yes you could even document that something is -not- sold in a >> structured fashion. > > How do you do that? To me "sells:blah=no" is clear: that blahs are, by > d

Re: [Tagging] Facts and opinions

with similar purpose has obvious advantages over a multitude of special purpose keys that are difficult to discover. Simon Am 08.01.2019 um 13:55 schrieb Martin Koppenhoefer: > > Am Di., 8. Jan. 2019 um 08:31 Uhr schrieb Simon Poole <mailto:si...@poole.ch>>: > > T

Re: [Tagging] Facts and opinions

Am 07.01.2019 um 16:12 schrieb Bryan Housel: > ... > On “both is OK”. the `service:vehicle` issue was because we can’t use the > same key `service=*` to contain both things like `tyres` (a few thousands) > and `driveway` (a few millions). Sorry, but the `service=tyres` has to go. > A few

Re: [Tagging] Dispute on tagging place=* in Turkmenistan

Am 02.01.2019 um 19:01 schrieb Kevin Kenny: > On Wed, Jan 2, 2019 at 11:39 AM Simon Poole wrote: >> In any case, on your original question, I would tend towards a national >> consensus that doesn't deviate too much from the population guidelines in >> the wiki, if at a

Re: [Tagging] Dispute on tagging place=* in Turkmenistan

At the danger of throwing a spanner in the works (or better sabots :-)): there is an ongoing discussion on place mapping. Mainly taking place here https://github.com/gravitystorm/openstreetmap-carto/pull/2816 Essentially  the relationship between administrative divisions and places/settlements is

Re: [Tagging] Feature Proposal - RFC - Top up

Am 27.12.2018 um 15:25 schrieb Martin Koppenhoefer: > > sent from a phone > > On 27. Dec 2018, at 11:44, Simon Poole wrote: > >>> much easier to evaluate than one like: >>> some_services=foo;characteristic_I_need_to_know;bar >> This is being directly d

Re: [Tagging] Feature Proposal - RFC - Top up

PS: btw this specific proposal is also "interesting" as it introduces mixed case keys, which in general have been considered nonos. Am 27.12.2018 um 11:44 schrieb Simon Poole: > There is a substantial difference between tagging a limited set of > physical properties (and

Re: [Tagging] Feature Proposal - RFC - Top up

There is a substantial difference between tagging a limited set of physical properties (and yes clearly some of this could have been done as a list too)  that are known in advance vs. moving an essentially unbounded list of fantasy names in to key space. The argument that semi-colons shouldn't be

Re: [Tagging] Benefits of namespaces

Am 17.12.2018 um 13:01 schrieb Paul Allen: > .. > > This isn't theoretical speculation.  The author of iD has, in the > past, expressed unhappiness > about such re-usability. > ... This is a specific to iD and not a general concern, and simply has to do with that in a lot of cases iD doesn't

Re: [Tagging] Can OSM become a geospacial database?

Just to inject a bit of OT here - the EN name of the Vierwaldstättersee is Lake Lucerne - the literal translation is "lake of the four forest settlements" (only loosely related to the notion of cantons) In both cases naming the lake  "Lucerne" or "Vierwaldstätten" would obviously be nonsense.

Re: [Tagging] Add some tag to identify disputed borders

I'm not a big fan of doing this. There are only a very small number of countries, maybe none, that don't have any sections of their borders that are disputed. While it can be argued that moving away from our de facto area of control model allows to reflect reality better, it also makes the

Re: [Tagging] Opening hours too long for OSM

e able to parse a large part (~15%) of the existing strings that are meaningful. See for example https://github.com/simonpoole/OpeningHoursParser (note that a really strict mode would throw out quite a bit more). Simon > > On 13/10/2018 12:35, Simon Poole wrote: >> >> Am 13.10.2018

Re: [Tagging] Opening hours too long for OSM

Am 13.10.2018 um 00:46 schrieb Tobias Zwick: > It is already part of the specification that "Mo-Fr 9-17" is possible. Actually it isn't, see https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification I don't think discussing changes to the opening_hours grammar is this thread is a

Re: [Tagging] Opening hours too long for OSM

Am 12.10.2018 um 18:37 schrieb Frederik Ramm: > Hi, > > On 10/12/2018 12:54 PM, Tobias Knerr wrote: >> I agree that this problem calls for a general solution, as it's not >> specific to opening hours. > ... > > Or can we afford to just skip mapping that detail? > It is all fine and dandy for us

Re: [Tagging] Opening hours too long for OSM

Am 11.10.2018 um 23:47 schrieb Jmapb: > ... >  Lengthening the field would be great, but failing that I suppose > opening_hours_1 is an ok stopgap, though it's unlikely there's any > end-user software that will look for it. One thing I'd recommend, > though, is not to end truncate the value

Re: [Tagging] Opening hours too long for OSM

. Am 12.10.2018 um 01:27 schrieb Simon Poole: > We have a number of keys for which the values can easily exceed 255 > chars besides opening_hours, lane destinations and conditional > restrictions are good candidates. Not to mention changeset tags. With > other words it is a general problem

Re: [Tagging] Opening hours too long for OSM

We have a number of keys for which the values can easily exceed 255 chars besides opening_hours, lane destinations and conditional restrictions are good candidates. Not to mention changeset tags. With other words it is a general problem which should be tackled with a general solution. One would

  1   2   3   >