Re: [Tagging] Please join the OSM accessibility initiative

[Simon Poole]

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.

Simon

Am 3. April 2024 14:58:30 MESZ schrieb bkil :
>We are in desperate need for new tags and tools to improve
>accessibility for both contribution and use. Please refer to the
>following page for a detailed scope and feel free to add yourself as a
>volunteer if you could give us a hand in any of the outlined areas:
>
>https://wiki.osm.org/User:Bkil/OSM_accessibility_initiative
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 details of why 
using a generic term for the products avoids cultural sensitivities 
outside of western Europe. That said the main issue with tagging these 
is that they haven't been mapped at all, and I don't see why changing 
the tagging will improve anything in that respect.


Simon



Anne
On 23/08/2023, 08:31 Amanda McCann  wrote:

 On Tue, 22 Aug 2023 23:53 +02:00, Anne-Karoline Distel 

 wrote:
  > I've created a proposal to map whether free period products are
  > available in a toilet which seems to become more common in recent years.
  > It think it's as valid as adding changing tables.
  >
  > https://wiki.openstreetmap.org/wiki/Proposal:Free_period_products
 


 Great Idea. How about adding something for the location of where the period
 products are. There is already
 `changing_table:location=wheelchair_toilet,female_toilet,male_toilet,…`

 PS: Remember that trans men might need period products too .
 --
 Amanda


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


OpenPGP_signature
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 
https://wiki.openstreetmap.org/wiki/Addresses#Buildings_with_multiple_house_numbers


OpenPGP_signature
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Help with new tags about wheelchair

[Simon Poole]

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 Wheelmap?

Because that answer is not quite correct, back in 2016 and for a couple 
of years Wheelmap had a version of their Android app that ran on googles 
Tango (Augmented Reality) platform, and with that they were measuring 
entrance widths (both for toilets and entrances in general) and ramp 
inclines (something you don't include in your tag list BTW).


While they never ported that to ARCore, there might still be interest in 
starting collecting more detail again, given that it now seems to work 
passably on a wider range of phones. With other words I would suggest 
that you discuss at least their experience with collecting more details 
with them and coordinate.


Simon



OpenPGP_signature
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Historic

[Simon Poole]

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 has.


Simon

Am 11.10.2022 um 15:15 schrieb martianfreeloader:

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 page
- In the forum

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


OpenPGP_signature
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Literal translation of street names

[Simon Poole]

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 Stone Street for 
Kamenita ulica. I found a few of these in Berlin, for example,Straße 
der Erinnerung translatedRoad of Remembrance. These are valid 
translations, but it isn't helpful for a map. If an english user of 
our map saw "Road of Remembrance", she won't be able to find that 
street sign, or explain to a taxi driver where she wants to go.


I think I've seen someone talk against such translations, but I can't 
find a wiki page that talks about it. I can create one if there is 
consensus that this is wrong tagging. Or maybe just add a few 
sentences about it on the name=* wiki page.


The problem is, he is doing valid work, so it feels wrong to just 
delete it. Another way to deal with this is to create a new tag, 
name:literal_translation:en=* or just literal_translation:en=*.


Another question, what is the right name:en=* in these cases, or is 
there none? Erinnerung Road?


Thanks!
Janko Mihelić

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


OpenPGP_signature
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 have the same value, 
semantically they are different and replacing level:ref with addr:floor 
which is what you were suggesting with what boils down to a mechanical 
edit with SC, will break SIT tagged buildings.


Am 18.12.2020 um 14:01 schrieb Mateusz Konieczny via Tagging:
1) this edits were not intended as changing anything but to document 
current tagging

practice

2) how Simple Indoor Tagging is being broken by either of this tags?

3) If SIT is broken by that tags, how it can be avoided? Recommending 
to use

level tag together with either of this two?


Dec 18, 2020, 13:34 by si...@poole.ch:

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
https://wiki.openstreetmap.org/wiki/Key:addr:floor

and created https://wiki.openstreetmap.org/wiki/Key:level:ref


Please, edit this pages if something can be improved.

Review of this pages also would be welcomed.

(edits triggered by
https://github.com/streetcomplete/StreetComplete/issues/1487

and done as part of survey of a tagging situation before a
potential implementation)

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





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


OpenPGP_signature
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 https://wiki.openstreetmap.org/wiki/Key:addr:floor 

and created https://wiki.openstreetmap.org/wiki/Key:level:ref 



Please, edit this pages if something can be improved.

Review of this pages also would be welcomed.

(edits triggered by 
https://github.com/streetcomplete/StreetComplete/issues/1487 

and done as part of survey of a tagging situation before a potential 
implementation)


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


OpenPGP_signature
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 involved as the 
maximum node limit on ways.


See

- https://github.com/openstreetmap/openstreetmap-website/issues/1711

- https://github.com/zerebubuth/openstreetmap-cgimap/pull/174

With the later giving some insights in to why simply declaring a limit 
is not a good idea. But putting a bound in place and expecting all tools 
to be handle relations up to that size (just as we currently do with 
ways) would be a good thing to improve robustness of the whole system.


Simon



OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

While I would try to avoid it, you can naturally simply duplicate the 
geometry (and you don't even need to duplicate the nodes to do that).


Am 04.11.2020 um 22:26 schrieb Andrew Harvey:


On Wed, 4 Nov 2020 at 20:10, Philip Barnes <mailto:p...@trigpoint.me.uk>> wrote:


On Wed, 2020-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 really useful I don't see why we
couldn't introduce a amenity=...pickup... tag.




But if such a dedicated pickup location is a carpark then it
needs amenity=parking, so it can't fit into the amenity key.


A pickup point will be a node within a car park area.

Its is already common to add amenity=bicycle_parking nodes within
amenity=car_park areas.


Why would it be a node within a car park? For example 
https://www.openstreetmap.org/way/366754575 
<https://www.openstreetmap.org/way/366754575> is the designated 
airport Uber, etc. pickup location, not some point inside the car 
park, but the whole car park itself.


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


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 really useful I don't see why we couldn't introduce a 
amenity=...pickup... tag.


Am 31.10.2020 um 23:50 schrieb Brian M. Sperlongano:
The use of the proposed access tagging on roads to indicate whether or 
not a private hire/rideshare can drive on them I think we can all 
agree is straightforward, but it gets muddy when talking about other 
types of infrastructure that this might apply to.


I would like to better understand how such access tagging would work 
in practice for an example at my local airport.  In that instance, the 
designated Uber pickup/dropoff location is a particular spot within a 
specific parking garage (tagged with amenity=parking + building=yes).  
Do I add private_hire=designated to the building?  Okay, that can 
work.  But then, adding operator=Uber doesn't work -- after all, Uber 
isn't operating the parking garage, they just have permission to make 
pickups at a particular signed location. This tells me that a POI 
that's separate from the parking garage object is needed to indicate 
the precise pickup location within the garage.  Are we saying that's 
amenity=taxi + private_hire=designated?  That doesn't work because a 
taxi stand implies on-demand transportation.  I would just ask that we 
consider the full picture of how designated private hire/rideshare 
tagging should be done at airports 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 not about taxi stands or anything similar, but about
access for Lyfts, Ubers, Grabs employees to streets and
infrastructure that they would not be able to utilize if they were
driving for themselves (including actual ride sharing :-)).
Example pick up and drop off access at airports and similar, this
might include access to taxi dedicated infrastructure too. This is
quite legit and no beef with the companies wanting to be able to
model this to improve routing for their drivers and customers.

Simon

Am 31.10.2020 um 15:23 schrieb Brian M. Sperlongano:

In the United States at least, there is a very real difference in
meaning between "rideshare" and "taxi" services when it comes
*specifically* to access at airports.  And I believe that is the
intent of this proposal: how do I tag the special area in the
airport where I must go in order to be picked up by XYZ rideshare
company?

At an airport, if you wish to take a taxi, you walk up to a taxi
stand (amenity=taxi), where the taxi cabs line up, and you take
the first taxi cab in line. This is an explicit area where only
taxis queue up.

Alternately, if you wish to take a "ride share", you are using an
app to make an arrangement with a specific vehicle and driver to
be picked up at a specific location.  In this case, airports
often (at this point, probably "usually") have a specified
location where such ride shares are allowed to pick up and/or
drop off passengers.

In some cases, the ride share pickup/drop-off locations have
specific areas that are different for different ride share
providers.  For example, at my local airport, due to
disagreements about how much these companies should pay the
airport for curb access (really), there is one location where you
can pick up a Lyft, and a separate location 100 meters away off
the airport property where you can pick up an Uber!

The point here is that in the US there is a very real distinction
between these two classes of objects, and the 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, 2020 at 6:36 AM Simon Poole mailto:si...@poole.ch>> wrote:

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 for
their operations.

Further, real rideshare services don't get special access
treatment anywhere I know of, outside of vehicle occupancy
regulations, which isn't surprising as real ride sharing
simply involves sharing costs and car on a trip that the
driver was going 

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

[Simon Poole]

I think there is a bit of a misunderstanding here.

This is not about taxi stands or anything similar, but about access for 
Lyfts, Ubers, Grabs employees to streets and infrastructure that they 
would not be able to utilize if they were driving for themselves 
(including actual ride sharing :-)). Example pick up and drop off access 
at airports and similar, this might include access to taxi dedicated 
infrastructure too. This is quite legit and no beef with the companies 
wanting to be able to model this to improve routing for their drivers 
and customers.


Simon

Am 31.10.2020 um 15:23 schrieb Brian M. Sperlongano:
In the United States at least, there is a very real difference in 
meaning between "rideshare" and "taxi" services when it comes 
*specifically* to access at airports.  And I believe that is the 
intent of this proposal: how do I tag the special area in the airport 
where I must go in order to be picked up by XYZ rideshare company?


At an airport, if you wish to take a taxi, you walk up to a taxi stand 
(amenity=taxi), where the taxi cabs line up, and you take the first 
taxi cab in line.  This is an explicit area where only taxis queue up.


Alternately, if you wish to take a "ride share", you are using an app 
to make an arrangement with a specific vehicle and driver to be picked 
up at a specific location.  In this case, airports often (at this 
point, probably "usually") have a specified location where such ride 
shares are allowed to pick up and/or drop off passengers.


In some cases, the ride share pickup/drop-off locations have specific 
areas that are different for different ride share providers.  For 
example, at my local airport, due to disagreements about how much 
these companies should pay the airport for curb access (really), there 
is one location where you can pick up a Lyft, and a separate location 
100 meters away off the airport property where you can pick up an Uber!


The point here is that in the US there is a very real distinction 
between these two classes of objects, and the 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, 2020 at 6:36 AM Simon Poole <mailto:si...@poole.ch>> wrote:


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 for their operations.

Further, real rideshare services don't get special access
treatment anywhere I know of, outside of vehicle occupancy
regulations, which isn't surprising as real ride sharing simply
involves sharing costs and car on a trip that the driver was going
to make anyway.

If there are actual legal differences between taxi and chauffeur
access somewhere, we could use chauffeur or chauffeur-driven as an
access tag (better suggestions welcome).

Simon



..


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 legally private hire so whilst there may be a case 
for access tags covering private hire there should not be a separate 
tag. If different companies use different points at an airport that 
can be covered by operator=*.


I would avoid the term chauffeur as it implies somebody who is part of 
the staff for somebody who also has a butler and a nanny.



Actually I quite like "private_hire" as an access value.


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 for their operations.


Further, real rideshare services don't get special access treatment 
anywhere I know of, outside of vehicle occupancy regulations, which 
isn't surprising as real ride sharing simply involves sharing costs and 
car on a trip that the driver was going to make anyway.


If there are actual legal differences between taxi and chauffeur access 
somewhere, we could use chauffeur or chauffeur-driven as an access tag 
(better suggestions welcome).


Simon

Am 30.10.2020 um 19:42 schrieb Clare Corthell via Tagging:

Hi Everyone,

Thank you for the input and feedback thus far, any outstanding 
commentary is welcome. Amendments to the proposal include a definition 
of rideshare, example companies, and comment responses on the 
Discussion page. In-line comments here.


Anyone who would like to comment or bring up outstanding questions, 
please do so for another week. At the end of next week, this proposal 
could move to voting.


Best,
Clare

On Thu, Oct 15, 2020 at 2:41 AM nathan case > wrote:


Clare: this is a good discussion to have.

It seems as though the emergence of rideshare services is still
being addressed at various legal levels but, at least in the UK,
rideshare vehicles are not classed taxis and so are not ordinarily
entitled to use bus/taxi lanes. If situations exist where
rideshares are specifically allowed (or not), and that access is
distinct from taxi or a regular motor_vehicle, then a key should
exist to denote that. I note that the proposal has been updated to
reflect such cases.

> Joseph Eisenberg: But you will also need to add a definition of a
"rideshare vehicle", since this will need to be translated for
places where Lyft and Uber do not operate, and where English is
not used (e.g. Indonesia). Unfortunately I don't see a good online
source for a definition.

Perhaps such definitions are dependent upon local/national
legislation. In your follow on examples, do those services enjoy
the same access rights as PSVs? If yes, then perhaps they should
simply be covered by that tag? If they do not, do they have any
additional or fewer access rights than simply motor_vehicle/cycle?
If not, then perhaps they should simply be covered by those
respective tags?


The legal designation could derive from venue/airport, local, county, 
state, or federal law. Just as u-turns are always technically legal in 
California unless prohibited, while in Washington they are prohibited 
unless permitted, there are local laws that are required to fully 
contextualize map data but are not represented within it. I don't 
foresee rideshare being default prohibited, so perhaps the example is 
too extreme, but nevertheless the goal is to encode the specific 
implications of local law for a given rideshare vehicle rather than 
law generally.


So a definition could be something along the lines of: “A private
hire vehicle, often booked through an online service or a mobile
application, that does not enjoy the same legal standing as a taxi
service. Exact definition may depend on local law but usually
denotes services such as Uber and Lyft.”

A taxi that also takes bookings/collects fares via an app is still
a taxi, in my opinion.

Regards,

Nathan

*From:*Joseph Eisenberg mailto:joseph.eisenb...@gmail.com>>
*Sent:* Thursday, October 15, 2020 12:32 AM
*To:* Tag discussion, strategy and related tools
mailto:tagging@openstreetmap.org>>
*Subject:* Re: [Tagging] Feature Proposal - RFC - Rideshare Access

Clare,

The "proposal" section currently fails to include the actual
proposal: that is, what new key and tags are you proposing to use?

It looks like the proposal is: "approve the use of the new key
"rideshare=" with values "yes" and "no" to specify legal access
for rideshare vehicles."

For the possible values, the expectation is that these include typical 
values 
 
for other vehicle access, such as {yes, no, designated, local, 
destination}. We typically encounter cases where the first two values 
are useful, as noted in the proposal. Cases of "designated" or 
"destination" access for rideshare vehicles are both plausible and 
possible. Possible keys are indicated in the existing Access page.


But you will also need to add a definition of a "rideshare
vehicle", since this will need to be translated for places where
Lyft and Uber do not operate, and where English is not used (e.g.
Indonesia). Unfortunately I don't see a good online 

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

[Simon Poole]

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 images for me even 
for very recent (that is uploaded last Friday) uploads, so I would 
suspect that this is simply a case of the UI not being adapted to their 
new business rules (it may be possible to still add further blurs, but 
removing them wouldn't seem to be possible).


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 tags to figure out if the way 
> denotes an
> interpolation line or an address range on a building.
> ...

As I suggested this, as a clarification: I wasn't  suggesting to add
this to the building outline, because as you say this wouldn't actually
work, but simply adding a short way within the building outline with the
interpolation information. I agree this is a hack, but it has the
advantage that if there is agreement and support for an on the building
tagging down the road, this can be moved to such a tagging without
having to resurvey.

Simon




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 apartment/unit numbers as in AUS for example.

Simon

Am 18.08.2020 um 11:02 schrieb Mateusz Konieczny via Tagging:
>
>
>
> Aug 18, 2020, 07:09 by andrew.harv...@gmail.com:
>
> > Data consumers see these hyphenated house numbers as one
> address, as well.
>
> Is that a problem? An address range can be considered a single
> address.
>
> > Create an address node for each housenumber and place each node
> somewhere on the building outline (or inside the building)
>
> I don't think that's a good idea, we should try to accurately map
> what's on the ground, when the street address is signposted as a
> range like "1-3" we should capture that as a single address "1-3"
> and not multiple addresses unless it's signed that way on the ground.
>
> It depends on what is actually on the ground, we are mapping addresses
> with addr:housenumber.
>
> Single object using 1-3 range? OK, 1-3 is correct and other versions
> would be incorrect.
>
> Single 1-3 signpost with three entrances? Then mapping each as a
> separate node with
> addr:housenumber=1, addr:housenumber=2, addr:housenumber=3 is preferable.
>
> Single entrance? Depends on a case, if there is later a clear split
> then three nodes are better
> than one range.
>
> Signposts are not sole address source, asking people - especially
> people living there -
> is also perfectly acceptable on the ground survey method.
>
>
> > If house numbers are associated with individual entrances, tag
> those numbers to entrance=* nodes.
>
> Doesn't work when the whole site and single main entrance have the
> address range.
>
> And in such case range may be OK or even preferable.
>
> > Separate the numbers by commas (e.g., 11,13,15) or semicolon
> (e.g., 11;13;15).
>
> why commas?
>
> Again I feel that's skewing what's actually represented on the
> ground, which is a single address which is a range and not
> multiple addresses.
>
> We are using addr:* to map addresses, not signposts. And in this
> specific case you are
> anyway unable to specify range.
>
> > Specify the range (e.g. 10-95). Note that there is a risk of
> ambiguity between two meanings:
> > When such a range is officially used for the entire house, this
> is the preferred method. In this case 10-95 is simply a label like
> any other. In this and other cases, house numbers officially
> contain a dash and are not meant to be treated as special.
> > When such a range is meant to be interpreted as a list of
> addresses, use addr:interpolation=* (described below) to emphasise
> this. Some mappers will add a short "virtual" way which allows
> them to put addresses 10 and 95 on separate nodes as normal. Some
> mappers will specify the range 10-95 on a single object, where the
> addition of the addr:interpolation=* tag disambiguates it from the
> "simply a label" meaning, specifying that it is indeed to be
> treated as a range. Both approaches are used in practice and there
> is little consensus.
> > Note that in some cases building or building complex has single
> address such as 3-5 that only looks like a housenumber range. As
> usual, do not convert such data blindly, without a verification.
> I think this is the best option, since it depends exactly what's
> happening on the ground.
>
> I think the only reasonable alternative is to have something like
> addr:housenumber:start=1 + addr:housenumber:end=3. Which is
> clearer that this is a range and allows data consumers to
> understand it better.
>
> On Tue, 18 Aug 2020 at 13:34, Paul White  > wrote:
>
> Hello,
>
> I wanted to raise a concern about tagging house numbers on a
> building using a hyphen to denote the address range (e.g 33-55
> Main Street). This is a bad idea because some areas in the
> United States and possibly elsewhere use hyphenated street
> numbers for individual dwellings.[1] Data consumers see these
> hyphenated house numbers as one address, as well. Other
> methods documented here
> 
> 
>  work
> better, in my opinion.
>
> I hope to get some input on this issue and the best path forward.
>
> Best, Paul
>
> [1]
> https://en.wikipedia.org/wiki/Queens#Streets
> 
> https://en.wikipedia.org/wiki/Fair_Lawn%2C_New_Jersey#Grid-based_address_system
> https://en.wikipedia.org/wiki/Address#United_States
>
>
> ___

Re: [Tagging] Apparent conflicting/redundant access tags

[Simon Poole]

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).

Am 7. August 2020 08:34:33 MESZ schrieb Niels Elgaard Larsen :
>On Thu, 6 Aug 2020 17:12:48 +1000
>Graeme Fitzpatrick  wrote:
>
>>OK, now you've all got me confused!
>>
>>I always thought that access=yes means that it is open to the general
>>public, while access=no means that it's not open to the public?
>
>
>The issue is that it becomes the default for all other transport mode
>access.
>
>I once had OsmAnd direct me to turn my car right on a very tiny path.
>
>It was tagged as highway=foot,access=yes
>
>
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 automated. That might well be faster
> in the API, where database accesses and data processing is faster. It
> would be slower than a dedicated database field, but would not require
> the database migration.
>
No this wouldn't be useful, because what you -actually- want is the
information when the tags have stayed the same, because they have
validated/surveyed, by definition this cannot be determined from
historic objects.

It is completely possible to add this functionality to the API in a
backwards compatible fashion, at the cost of a long per tag in the
current table (assuming that we don't need the information for historic
object versions, so at a reasonable cost space wise. There are a couple
of semantic issues that need to be considered but definitely not rocket
science. Where the big effort is likely adapting the internal tools
(database dumps etc), cgi-map and in the end migrating the database.

If I can find some time over the next months I might prototype this, but
if somebody can do it earlier pls be my guest.

Simon

PS: we just had this discussion on tagging btw in case nobody noticed.




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] amenity=customer_service RFC

[Simon Poole]

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, complaints, edits to the page (especially concerning
> grammar, typos and clarity)
> are highly welcomed
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 country I'm resident in there are nearly no post code
boundaries that are exactly the same as the administrative boundary with
the same name).

Simon

Am 30.06.2020 um 13:59 schrieb Florian Lohoff:
> Hi,
> i am running some address validation pipeline as others do aswell. In
> Germany we have the case that most of the time the addr:city
> on the addresses matches the name on the admin_level 8 boundary
> (Sometimes admin_level 6).
>
> So normally you have:
>
>   boundary=administrative
>   admin_level=8
>   name=Gütersloh
>
> And all addresses carry a
>
>   addr:city=Gütersloh
>
> Now there are some exceptions. One example i always paint red in the
> validator is 33428 Marienfeld.
>
> For Marienfeld there is an admin_level=8 which carries the
> name=Harsewinkel which is correct for all "suburbs" or villages
> belonging to Harsewinkel except Marienfeld.
>
> Marienfeld itself carries a admin_level=9
>
> So i'd like to have a place in OSM where i store this exceptions
> information (There are plenty other places which have this
> exception).
>
> So i would propose to set an "addr:city=Marienfeld" on the admin_level=9
> boundary. So the address validator knows that addresses contained within
> this al9 should carry a different addr:city than they normally would
> using the al8.
>
> Other ideas?
>
> Flo
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Access tag abuse examples

[Simon Poole]

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
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

Am 19.05.2020 um 12:01 schrieb European Water Project:
> ...
> Dear Simon,
>
> What do you mean by  "+ version" ? Are you referring to a timestamp or
> a something else ?

The version of the object, so lets look at

https://www.openstreetmap.org/node/416064315 (version 7)

But you could equally simply lookup

https://api.openstreetmap.org/api/0.6/node/416064315/7

or if you had an older version

https://api.openstreetmap.org/api/0.6/node/416064315/4 (version 4)

these links are guaranteed to always return the same object, frozen in time.

Simon


>
> For 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:
>
> 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 on your criteria) is still the "same object", update
> version in your reference
>
> - if the last version is deleted or your criteria for it being the
> same object doesn't hold, search in the vicinity for a replacement
> object.
>
> Doing the same for Ways and Relations requires including a
> location reference of some kind as geometry changes are not
> reflected in the versions, but can work in principle the same.
>
> Simon
>
> Am 19.05.2020 um 09:43 schrieb European Water Project:
>> Dear All,
>>
>> I am looking for a way to create permanent links  to specific
>> objects (fountains and cafés) with images within our application
>> ... and I have a couple of questions. 
>>
>> How quickly do OSM node and ways numbers mutate ?  What
>> percentage should I expect to change each year.  If the
>> percentage of ids mutates slowly enough .. maybe this is still
>> the best bad short term option ? 
>>
>> I was pointed to this wiki : 
>> https://wiki.openstreetmap.org/wiki/Permanent_ID  
>>
>> On the discussion page, it is mentioned that a solution is being
>> targeted for end 2020 . Will there be a tool to translate actual
>> osm node and ways numbers to the new permalink ids. 
>>
>> Apparently Mangrove uses GEO URI to create perma links towards
>> objects. https://en.wikipedia.org/wiki/Geo_URI_scheme. How do
>> they deal with node repositioning ?  I could create a link name
>> with first 5 latitude num followed by first 5 longitude num...
>> but as soon as someone moves the node I would get a broken link... 
>>
>> Thanks for your help and advice
>>
>> Best regards,
>>
>> Stuart 
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/tagging
> ___
> Tagging mailing list
> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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
on your criteria) is still the "same object", update version in your
reference

- if the last version is deleted or your criteria for it being the same
object doesn't hold, search in the vicinity for a replacement object.

Doing the same for Ways and Relations requires including a location
reference of some kind as geometry changes are not reflected in the
versions, but can work in principle the same.

Simon

Am 19.05.2020 um 09:43 schrieb European Water Project:
> Dear All,
>
> I am looking for a way to create permanent links  to specific objects
> (fountains and cafés) with images within our application ... and I
> have a couple of questions. 
>
> How quickly do OSM node and ways numbers mutate ?  What percentage
> should I expect to change each year.  If the percentage of ids mutates
> slowly enough .. maybe this is still the best bad short term option ? 
>
> I was pointed to this wiki : 
> https://wiki.openstreetmap.org/wiki/Permanent_ID  
>
> On the discussion page, it is mentioned that a solution is being
> targeted for end 2020 . Will there be a tool to translate actual osm
> node and ways numbers to the new permalink ids. 
>
> Apparently Mangrove uses GEO URI to create perma links towards
> objects. https://en.wikipedia.org/wiki/Geo_URI_scheme. How do they
> deal with node repositioning ?  I could create a link name with first
> 5 latitude num followed by first 5 longitude num... but as soon as
> someone moves the node I would get a broken link... 
>
> Thanks for your help and advice
>
> Best regards,
>
> Stuart 
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Simon Poole]

I was just making a statement of fact, not arguing one way or the other.
The original reason for using HAE in the ele tag was exactly what Kevin
claimed what would be the only sensible use of the HAE value. That it
probably was a bad idea because it didn't take the realities of mapping
in to account (as far as these could even be known at the time) doesn't
affect the original intent.

The really only open question is: do we consider ele so burnt that it
should just go away and we use a different tag (for example
ele:regional, though I would be against that specific key) for "height
indicated 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 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 to calculate
>> datum specific heights easily after the fact.
> Yes, but this is a ridiculous stramwan.   HAE and height above wgs84
> geoid are equally well defined, but one (height above geoid) is what is
> used for height and also happens to be almost matching all civil height
> systems.
>
>
> The real point here is that people want to take data that has a number
> but not a datum and enter it and feel good about themelves, instead of
> realizing and admitting that they are doing something fundamentally
> wrong.  I am perfectly ok with entering a height that has no datum, and
> having some meta key that basically says that the height value is
> inaccurate, and perhaps "ele:datum=unknown" is good for this, crisply
> denoting that the height is without a solid basis.
>
> But, I find it unreasonable that people want to legitimize this sort of
> confusion, rather than mark it as confusion as a warning to others.



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Simon Poole]

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 to calculate
datum specific heights easily after the fact.




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Simon Poole]

The previous versions of the page in particular the one that was
actually voted on (in 2007) does -not- have that reference, see also
https://wiki.openstreetmap.org/wiki/Talk:Key:ele for discussion on the
issue back to 2007.

As to the original page being German, well that 2007 is the time the
German speaking community discovered OSM and started what actually
turned it in to a success. Pretending that things didn't happen because
they were originally in German at the time, is negating large bits of
OSMs history.

Simon

Am 04.05.2020 um 12:04 schrieb Martin Koppenhoefer:
> Am Mo., 4. 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 2013 the ele entry was fiddled to point
> to the
> height above geoid.
>
>
>
> in 2013 the altitude page was not really created yet, there was only a
> page in German which hardly can be seen as relevant for the global
> project. The "key:ele" page already referred to the geoid rather than
> the ellipsoid in September 2008, as it said "height above sea level":
> https://wiki.openstreetmap.org/w/index.php?title=Key:ele=next=125595
> "Elevation (height above sea level) of a point in metres."
>
> Generally, the "altitude" term does not seem to catch it at all, it
> appears to mean a height _above_ ground, while with the "ele" tag and
> variations we are aiming at recording the actual ground elevation.
>
>
>
> This leaves us with
>
> a) conflicting definitions in the wiki (not the first time)
>
> b) a tag de-facto redefined after multiple years of use (natural=tree
> anybody?)
>
>
>
> not really comparable, because "a tree" is very clear, "a ground
> elevation" isn't (because it refers to a reference which isn't given)
>
>  
>
>
> Naturally the correct way to solve the issue would have been to
> introduce a new tag with the appropriate semantics and then let
> ele die
> out. Given that the mess has already happened it could be argued
> that we
> might as well use ele with the semantics that have been proposed for
> ele:regional, because that is what it "mostly"* has been used for.
>
>
>
> this would mean repeating the same mistake as 2013, continue to use
> the same tag for which it was already discovered that the values are
> referring to different references (well knowing, that not all values
> refer to the definition, some are referring to the WGS84 ellipsoid,
> some are referring to a geoid)
>
>
> Cheers
> Martin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC ele:regional

[Simon Poole]

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 the ele entry was fiddled to point to the
height above geoid.

This leaves us with

a) conflicting definitions in the wiki (not the first time)

b) a tag de-facto redefined after multiple years of use (natural=tree
anybody?)

Naturally the correct way to solve the issue would have been to
introduce a new tag with the appropriate semantics and then let ele die
out. Given that the mess has already happened it could be argued that we
might as well use ele with the semantics that have been proposed for
ele:regional, because that is what it "mostly"* has been used for.

Simon

* if would naturally be nice if that wasn't just based on speculation.

Am 04.05.2020 um 02:37 schrieb Greg Troxel:
> Martin Koppenhoefer  writes:
>
>> I’m asking for comments on 
>> https://wiki.openstreetmap.org/wiki/Proposed_features/ele:regional
> Two big comments:
>
>   First, the current wiki documentation about ele and Altitude should be
>   really straigthened out, so that we have a basis for what we are
>   comparing to.
>
>   Second, the notion of a single regional vertical datum doesn't really
>   work.  In the US, that could be the old NGVD29, or the current NAVD88.
>   Plus, we are about to get NATRF2022.  However, all of these are within
>   a meter or so, and in terms of vertical data in OSM, that's not really
>   a big problem.  So if there is going to be precision, then we should
>   follow GIS and have an explicit datum.  I would say an EPSG code is
>   sensible -- see the proj package for canonical values.
>
>
>
> As for ele/Altitude, there is great confusion out there about "WGS84"
> and two separate concepts:
>
>   height above the ellipsoid.  Often written HAE. The ellipsoid is a
>   mathematical surface that is NOT a surface of equal gravity.  While
>   geodesists and geodetic surveyors use it, and while it's part of the
>   calculations within GPS, I am not aware of a single vertical datum in
>   use in any country that is relative to the ellipisoid.  Note that
>   water does not flow "downhill" when "down" means to a lower value of
>   HAE.  Water is hugely important in elevation and mapping.
>
>   height above geoid, or height above a reference equal-gravity surface,
>   or height above sea level.  (Yes, I realize that "sea level" is a huge
>   can of worms.)   This is more or less what every height system uses or
>   intends to use.
>
>
> In WGS84, one gets from the base computation lat/lon and a height above
> the ellipsoid.  This is purely a geometric answer and is totally
> disconnected from grravity.  Then, GPS receivers use a gravity model to
> compute the offset from the ellipsoid and the reference gravity surface
> (which is more or less the "sea level surface"), and they them use that
> to get a "height above sea level".  Receivers that display to humans
> display this sea level height.  NMEA has that same sea level height.
>
> (Android stands alone in that the API returns height above ellipsoid.
> That's not wrong, but it is unusual.  IMHO how Android defines an
> interface is irrelevant to OSM's definitions.)
>
>
> When people say "WGS84 altitude", they mean the height above the WGS84
> equal-gravity surface as computed from the ellipsoidal height and the
> gravity model.  This is sort of 0m at sea level.  Note that the
> ellipsoid can be 100m different from this equal-gravity surface, and is
> often significantly different.  It's ~30m in Boston and I hear it's 50m
> in Switzerland.  Nobody who says "WGS84 altitude" really means "WGS84
> ellipsoidal height".  If they did, they would say "WGS84 ellipsoidal
> height".
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 mtb:scale:imba on any kind of trail where signage at
> the site notes an IMBA rating, in this way it's verifiable based on
> the sign. I don't know what "bikepark" and "north shore" mean here but
> while some of these trails which have an IMBA rating can be
> consider together as part of a collection of trails and that
> collection does have a name sperate to the individual tracks (which I
> guess is what bikepark means) others which do have signposted IMBA
> ratings are standalone and not part of a named collection of trails.
>
> So if it has an official or signposted IMBA rating, it should be
> tagged regardless of the trail being "natural" or with "artificial
> obstacles" and regardless if it's part of a mountain bike "park" or not.
>
> On Wed, 22 Apr 2020 at 17:29, Joseph Eisenberg
> mailto:joseph.eisenb...@gmail.com>> wrote:
>
> Another user would like to redefine the definition of
> "Key:mtb:scale:imba" 
>
> See suggestions
> at https://wiki.openstreetmap.org/wiki/Talk:Key:mtb:scale:imba:
>
> This tag was approved in the
> proposal https://wiki.openstreetmap.org/wiki/Proposed_features/mtb:scale
> - with the description "The IMBA Trail Difficulty Rating System
> shall be used for bikeparks. Especially for North Shore. It is
> adapted to mtb trails with artificial obstacles. For "natural"
> trails it is advised to use the mtb:scale/mtb:uphill:scale." -
> linked
> to 
> http://www.imba.com/resources/trail_building/itn_17_4_trail_difficulty.html
>
> Can other mappers who use this tag frequently confirm whether it
> is limited to specifically designed and built bike trails, like
> those found in "bikeparks"?
>
> -- Joseph Eisenberg
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 here any actual differentiation between the two values
> both are often badly used to describe the current function
> of the building and not what it look like.
> the description of building=civic said "A building hosting any civic
> amenity", so it's nothing related to what the building look like.
> imho data user can't do anything with that
> and as a contributor, I don't use any of them
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] building=public vs. building=civic

[Simon Poole]

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 by some wiki-fiddling and leveraging iD, has now
outstripped the "public" value considerably in popularity.

In any case the question is here any actual differentiation between the
two values, or are they effectively synonyms and just one needs to be
presented?*

Simon


*If that is the case then iD is oddly inconsistent in that it replaces 
amenity=public_building with building=public, but uses building=civic
when searching for "public building".


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

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

[Simon Poole]

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.
>
>
> I was hoping some would understand better by reversing the positions.
>
> The general norm all over the world is that most places -don't-
> have names in languages that are not used locally.
>
> Agreed.  There are a lot of named places in the world, ranging from
> countries
> down to short side-streets.  But some, the important and/or well-known
> ones,
> do have names in other languages.
>
> Pretending that they do isn't a useful concept and yes they
> typically won't have transliterations either.
>
> I'm not pretending the street I'm on has a name in Mandarin.  But the
> country I'm in does.  As does the capital of my country.  My town,
> probably not.
>
> There is valid reason to permit foreign-language names where such exist
> and to permit transliterations where orthography is sufficiently different
> to make the local name incomprehensible.  Duplicating the name=*
> in other languages than the local one(s) isn't sensible.
>
> -- 
> Paul
>


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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
transliterations either.

Am 27.03.2020 um 13:21 schrieb Paul Allen:
> On Fri, 27 Mar 2020 at 11:47, pangoSE  > wrote:
>
> Does it matter what I as a swede think?
>
> Perhaps.  It depends how you answer my question below. :)
>
> Names are (in my view) socially constructed and constantly agreed
> upon by the users of the language. I don't speak Swiss High German
> so I'm not really in a position to judge what to call this city in
> that language. IMO OSM is not a suitable place for speakers of
> Swiss High German
>
>  [...]
>  
> Does the dialect of Swedish you speak have different names for various
> well-known locations in the world that differ from the names used by
> people
> living there?  English does.  We use Germany for Deutschland.  We use Roma
> for Rome.  We use Switzerland for Helvetica.  Etc.  The French use Londres
> for London and Royaume Uni for the United Kingdom.
>
> If we English speakers are looking at a map of the world, we prefer to see
> our own names for places.  The media here don't report an earthquake
> in Roma
> but an earthquake in Rome.  They don't report a general strike in
> Deutschland
> but a general strike in Germany.  They don't report an avalanche in
> Helvetica
> but an avalanche in Switzerland.  So if we're interested in seeing on
> a map
> where those places are we'd like to see them in English, not names we're
> unfamiliar with.  I have no idea what Sverige is, but I've heard of
> Sweden.
>
> OTOH, if we're tourists we'd like the option to see both.  I want to go to
> Munich from Berlin but I can't find Munich on the map because it's
> showing the German name.  But if the map shows only English names
> (where available) I don't know what to look for on road signs.
>
> You might also want to consider different orthographies.  Even if you
> use the same word (phonetically) for Mecca that Saudi Arabians do,
> could you find the place on a map where it is labelled مَكَّةُ
>
> -
> Paul
>


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

Just using the entry for your place, do you really think that an entry
like say

Swiss High GermanHärnösand

makes sense? (Swiss High German is de-CH).

Simon

Am 27.03.2020 um 10:07 schrieb pang...@riseup.net:
> Hi Simon.
>
> Do you have a link? The Municipality I live in has sensible names in
> WD https://www.wikidata.org/wiki/Q3240427
>
> Does it matter to us in OSM if it "has the name"? I'm thinking that we
> outsource all the naming to WD to deal with and fight over.
> In OSM we could instead concentrate on e.g. what language codes to
> display on osm.org e.g. name_osm=sv for a city with dominant Swedish
> population and name_osm=se for a town/city where most are Sami.
> In the case of double naming on the ground we could have something
> like: name_osm= code1 / code2
> Where code1 is the e.g. the Welsh and code2 is the English name.
>
> 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 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 a Swiss-German name, it
> -doesn't- have names in any of the other 31 languages that are listed.
>
> Simon
>
> Am 25.03.2020 um 11:00 schrieb pang...@riseup.net:
>> Honestly I don't think it makes sense for OSM to have names at
>> all on objects which has a Wikidata reference. We are just too
>> small a community to keep this updated and it has little value to
>> duplicate to the efforts made by others.
>> If any names I suggest we have a bot autoupdating all name tags
>> according to the values in Wikidata. If there is no Wikidata item
>> it should be found/created.
>> It really is'nt hard to populate a map with geographical data
>> from OSM and query the names the user wants to see from WD.
>> This offloads a huge burden as I see it.
>> All our tools that currently invites our users to include a name
>> could be adapted so that the user is aware that OSM is about
>> geodata and names are for WD and best stored/updated there.
>> If we allow a name to be set only when no qid we avoid the bulk
>> of these problems.
>> When a qid is set a bot could remove all names for languages
>> already present in WD.
>>
>> On March 25, 2020 10:45:03 AM GMT+01:00, Andrew Hain
>>  wrote:
>>
>> Why on earth would we not (excluding exceptional copyright
>> issues) want to have lots of different name:XX tags?
>>
>> --
>> Andrew
>>
>> 
>> 
>> *From:* Frederik Ramm 
>> *Sent:* 25 March 2020 09:26
>> *To:* Tag discussion, strategy and related tools
>> 
>> *Subject:* [Tagging] Which languages are admissible for
>> name:xx tags?
>>  
>> Hi,
>>
>> the "name:xx" tags are something of an exception in OSM
>> because while we
>> defer to "local knowledge" as the highest-ranking source
>> normally, this
>> is not being done for name:xx tags. It is possible for no
>> single citizen
>> of the city of Karlsruhe to know its Russian name, but still
>> a Russian
>> name could exist. Who is the highest-ranking source for that?
>>
>> My guess is that about 5% of name:xx tags in OSM actually
>> represent a
>> unique name in its own right; all others are either copies of
>> the name
>> tag ("this city does not have its own name in language XX but
>> I want
>> every city to have a name:xx tag so I'll just copy the name
>> tag"), or
>> transliterations (or, worst case, even literal translations).
>>
>> A while ago we had a longer discussion about Esperanto names;
>> in that
>> discussion, it was questioned whether Esperanto could be in
>> the name tag
>> but nobody disputed that adding name:eo tags is ok, even though
>> Esperanto is an invented (or "constructed") language.
>>
>> Yesterday someone added a few dozen Kli

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

[Simon Poole]

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 a Swiss-German name, it -doesn't- have names in any of
the other 31 languages that are listed.

Simon

Am 25.03.2020 um 11:00 schrieb pang...@riseup.net:
> Honestly I don't think it makes sense for OSM to have names at all on
> objects which has a Wikidata reference. We are just too small a
> community to keep this updated and it has little value to duplicate to
> the efforts made by others.
> If any names I suggest we have a bot autoupdating all name tags
> according to the values in Wikidata. If there is no Wikidata item it
> should be found/created.
> It really is'nt hard to populate a map with geographical data from OSM
> and query the names the user wants to see from WD.
> This offloads a huge burden as I see it.
> All our tools that currently invites our users to include a name could
> be adapted so that the user is aware that OSM is about geodata and
> names are for WD and best stored/updated there.
> If we allow a name to be set only when no qid we avoid the bulk of
> these problems.
> When a qid is set a bot could remove all names for languages already
> present in WD.
>
> On March 25, 2020 10:45:03 AM GMT+01:00, Andrew Hain
>  wrote:
>
> Why on earth would we not (excluding exceptional copyright issues)
> want to have lots of different name:XX tags?
>
> --
> Andrew
>
> 
> *From:* Frederik Ramm 
> *Sent:* 25 March 2020 09:26
> *To:* Tag discussion, strategy and related tools
> 
> *Subject:* [Tagging] Which languages are admissible for name:xx tags?
>  
> Hi,
>
> the "name:xx" tags are something of an exception in OSM because
> while we
> defer to "local knowledge" as the highest-ranking source normally,
> this
> is not being done for name:xx tags. It is possible for no single
> citizen
> of the city of Karlsruhe to know its Russian name, but still a Russian
> name could exist. Who is the highest-ranking source for that?
>
> My guess is that about 5% of name:xx tags in OSM actually represent a
> unique name in its own right; all others are either copies of the name
> tag ("this city does not have its own name in language XX but I want
> every city to have a name:xx tag so I'll just copy the name tag"), or
> transliterations (or, worst case, even literal translations).
>
> A while ago we had a longer discussion about Esperanto names; in that
> discussion, it was questioned whether Esperanto could be in the
> name tag
> but nobody disputed that adding name:eo tags is ok, even though
> Esperanto is an invented (or "constructed") language.
>
> Yesterday someone added a few dozen Klingon names to countries in
> OSM. I
> have reverted that because of a copyright issue, but I think we also
> need to discuss which languages we want to accept for name:xx tags.
>
> In my opinion, a name:xx tag should only be added if you can
> demonstrate
> that people natively speaking the living language xx are actually
> using
> this name for this entity. I think we have a very unhealthy
> inflation of
> names in OSM that are added by "single-purpose mappers" - they
> come in,
> stick a name:my-favourite-language tag onto everything, and go away
> again. Nobody knows if these names are even correct, and nobody cares
> for their maintenance. The country North Macedonia changed its name
> almost one year ago, yet roughly half of its ~ 170 name tags are still
> what they were before this change. Nobody cares; these names suggest a
> data richness that is not backed up by an actual living community that
> cares for them.
>
> What are your opinions on which languages should be accepted in name
> tags? What do you think about
>
> * niche constructed languages (say, FredLang which has 2 words I
> invented just now)
> * popular constructed languages (Klingon, Elvish) - note place
> names in
> these languages will often be algorithmically derived from the English
> or local name
> * "serious" constructed languages (Esperanto)
> * languages that once existed but are not natively spoken any more
> (Roman)
> * languages that are natively spoken but their speakers do not have
> their own name for the entity in question (instead they use the same
> name the locals use, possibly transcribed into a different alphabet)
> * ...
>
> Or if you don't have the time to think about this in detail, just
> answer
> the question: tlhIngan Hol - Hlja' or ghobe'?
>
> Bye
> Frederik
>
>
> 

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

[Simon Poole]

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 important tools.

Simon

Am 15.01.2020 um 12:57 schrieb marc marc:
> Le 15.01.20 à 12:49, Mateusz Konieczny a écrit :
>> Anyone with opinion on that topic is welcomed to comment in this
>> discussion on the OSM Wiki.
> I'm very unhappy with that.
> some tools use wiki and not data items (for ex taginfo)
> doing that destroy usefull information.
> in fact I'm unhappy with the write acces to data items that has been
> done too early, all major tools must first be migrated to the dataitems.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 = 
> free_water:container =
> free_water:table=  
>
> How long does it typically take for the tag allocation decision
> process to be completed?  Do you have an example wiki proposal page ? 

To be clear "formal" approval is completely optional, documenting what
you are using is best practice, discussing what could work and trying to
find a consensus is wise.

Currently I see the usual problem that the discussion is trying to solve
the general problem. Is anybody actually interested in if free water is
dispensed in other than bring your own container/bottle scenarios?

Simon

>
> Best regards,
>
> Stuart 
>
>  
>
>
> Message: 2
> Date: Mon, 13 Jan 2020 19:57:02 +0100
> From: Hauke Stieler  >
> To: tagging@openstreetmap.org 
> Subject: Re: [Tagging]  Tagging Free Water for cafés, bars,
>         restaurant
> Message-ID:  >
> Content-Type: text/plain; charset="utf-8"
>
> Hi Stuart,
>
> > The proposal below does not seem optimal, but if that is what is
> decided
> > we will write wiki instructions in this manner.
> No decisions have been made so far. Currently all these mails just
> contain ideas and discussions.
>
> I'm personally a fan of the namespace scheme, the one with the ":"
> separating parts of a tag. You'll find this e.g. on addresses:
>
>         addr:street=*
>         addr:city=*
>         addr:housenumber=*
>         ...
>
> Or also for parking situations:
>
>         parking:lane=*
>         parking:lane:left=*
>         parking:condition=*
>         ...
>
> This semantic separation of a key creates a nice structure and
> organizes
> this huge collection of possible tags into groups.
>
> > I still prefer free_water_refill=yes/no  free_water_table=yes/no
> Because the beginning of these two tags are the same, for me
> personally
> it's a reason to change them into "free_water:..." tags.
>
> Using this scheme, I can also imagine the following tags (just ideas,
> the keys and values are probably not optimal):
>
> free_water=
> free_water:container=
> free_water:table=
> (maybe more...)
>
> However, in the end, there must probably be a tag proposal (a wiki
> page
> describing how the final tags should look like, what they exactly
> mean,
> when to use them, what use-cases do they have, etc.). Everybody
> can vote
> for or against the proposal, therefore it's in the end on the
> community
> to decide what tags become "official".
>
> Hauke
>
> -- next part --
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: OpenPGP digital signature
> URL:
> 
> 
>
> --
>
> Message: 3
> Date: Mon, 13 Jan 2020 20:01:56 +0100
> From: European Water Project  >
> To: tagging@openstreetmap.org 
> Subject: Re: [Tagging]  Tagging Free Water for cafés, bars, (Martin
>         Koppenhoefer)
> Message-ID:
>        
>  >
> Content-Type: text/plain; charset="utf-8"
>
> >
> >    2. Re:  Tagging Free Water for cafés, bars, (Martin Koppenhoefer)
> >
> > Martin, Italy is amazing. Apparently there are more than 100,000
> fountains in Italy. On the 24th of April, we are planning a
> fountain hunt
> in Rome with the My-D.org. We should be 20 people including locals
> (just in
> case you live there).
> re: amenity=drinking_water
> France is complicated and the lobbies have made almost all
> perfectly good
> water fountains labelled "non potable". Just across the borders in
> Switzerland and Italy all the fountains are good to drink..
>
> Price can be an incentive, but unless the waste producer pays all true
> indirect externalities the cost will always be minimal for PET.
>
>
> > 3. Re:  Tagging Free Water for cafés,  bars, (Philip Barnes)
> >
>
> >>>Philip, Yes, like the US and France. We believe that it
> should be
> that way everywhere. No one should have to create single-use waste
> to keep
> themselves hydrated.
>
> >
> >
> >
> > Message: 2
> > Date: Mon, 13 Jan 2020 17:50:20 

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

[Simon Poole]

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.
>
> Are there actually signed, verifiable inline skate routes?
>
> Should a rare tag like this be in Map Features?
>
> Similar questions about route=running - are there real, signed running
> routes which are separate from walking or hiking routes?
>
> - Joseph Eisenberg
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] addresses on buildings

[Simon Poole]

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 not a
> building.
> Thai also helps navigation devices to get you to the actual entrance
> and not only near the building.
> But this is Italy-specific.

Switzerland is similar (the national address dataset is a bit hit and
miss if the location is actually usable, but that's life).



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging of bicycle anti-features

[Simon Poole]

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 might want to apply weighting so that an earlier
exit from the cycleway can be taken, or display/sound a warning in a
navigation app (note imho if you are not paying enough attention that
you would see this any way you are doing something wrong). 

Simon

Am 28.10.2019 um 19:45 schrieb Tobias Zwick:
> We know how to tag certain bicycle features such as the "advanced stop line" 
> [1]
>
> It would be interesting to tag also anti-features. Most commonly, a cycleway 
> that just ends  without merging it back onto the street. Currently, such a 
> situation would be tagged the same as a track that is merged correctly onto 
> the road. This situation is especially hindering if combined with cars 
> parking closely to each other on the sides of the road.
>
> How could this be tagged, for cycleways mapped on the road-way? Any 
> suggestions how a tag for this could be named?
>
> Greetings
> Tobias
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:cycleway%3Dasl
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 next line said destination:symbol=hospital
> it's better.

And using it would be consistent with using destinations on lanes
https://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details#destination:symbol


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



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 + amenity=hospital"
 https://wiki.openstreetmap.org/wiki/Relation:destination_sign
>
> I had a look at the original proposal, and it does not contain the
> word 'amenity'.
> Thus I conclude it had been later fiddled into the wiki page.
>
> Anyway looking into the voting results the whole proposal looks fiddled,
> the proposer counts some of the No votes as approvals :-o
>
> tom
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 2019 at 00:53, Warin <61sundow...@gmail.com
> > wrote:
>
> disused:*=* means it cannot presently be used for its intended
> purpose. That does not mean it does not exist.
>
>
> Correct.
>
> How renders chose to display that is up to them.
>
>
> Also correct (sadly).
>
> But the tagging is correct and truthful.
>
>
> Using disused=yes is correct and truthful.  Using disused:foo=bar is
> ALSO correct and truthful.
> Both are documented as valid ways of tagging disused objects.
>  
>
> Choosing another tag because it renders the way desired is not a
> good thing.
>
>
> Only because the behaviour is not guaranteed across renderers or even
> over time for a single
> renderer.  However, choosing one correct and truthful tag over an
> alternative correct and
> truthful tag because of how it renders in one renderer is not wrong
> (even though some may
> consider it unwise).
>
> For those who  use disused=yes because it renders .. are you
> equally happy to have amenity=toilet rendered when it has
> disused=yes on it???
> How about a pub, atm etc etc...
>
>
> You mean like the toilet near me that has been shut down because the
> council can't afford to run it
> but which a local non-profit organization hopes to take over and
> re-open?  The building still
> exists, but if i use disused:building=yes it vanishes from standard
> carto.  It's no longer being
> used as a toilet but may be in the future, but if I add disused=yes
> then the toilet symbol renders
> so people turning up there with full bladders are going to be upset.
>
> Or how about the many disused quarries near me?  They still exist. 
> They are visible.  Some
> of them pose a hazard.  If I use disused:landuse=quarry they vanish
> from standard carto.
>
> Renders need to distinguish between active features and those no
> longer in service, but
>
> still existing. That is a rendering issue not a tagging issue.
>
>
> How could renderers tell the difference unless the tagging informs
> them?  One way would
> be for them to render only physical objects in the disused namespace,
> so that
> building:disused=yes renders but disused:amenity=toilets does not get
> a toilet symbol.
> That leaves a problem if somebody uses building=yes + amenity=toilets
> + disused=yes,
> although that's still possible for a renderer to figure out.  However,
> many renderers do
> not currently make those distinctions.
>
> The other way is that renderers agree to support a tagging convention
> that disused:foo=bar
> suppresses rendering but disused=yes does not (standard carto is ahead
> of the game here).
>
> There ARE cases where disused objects should be rendered and there ARE
> cases where they
> should not.  We SHOULD have a tagging convention that at least one
> major renderer supports
> so that we can control this.  Mostly it seems that disused physical
> objects should render
> but disused properties should not, although that may not always be the
> case, so two
> ways of tagging disused objects leaves the decision up to the mapper
> rather than relying
> on a heuristic that may sometimes be wrong.
>
> Moaning that we have two tags used to do the same thing which mappers
> choose between
> because of rendering isn't helpful.  Warning that those choices may be
> incorrect in different
> renderers, or may suddenly stop behaving in the expected way in
> standard carto is better.
> A documented agreement with (at least standard) carto on expected
> behaviour that allows
> disused objects to be rendered correctly would be best of all.  Except
> this is OSM and we
> don't do joined-up thinking.
>
> -- 
> Paul
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 form provides
>> access to clothes washing machines and space, because even a completely
>> normal laundromat facility is not a shop. In hindsight it should have
>> always been amenity=laundry (or similar) but that is a done deal.
>
> IMHO we shouldn’t ignore classifications. It would be easier to follow your 
> argument if the tag was indeed amenity=laundry but as it isn’t, the tag 
> should be used for what in OpenStreetMap is a shop (a business selling goods 
> or services)

Then nearly all amenities and leisure objects would be shops, consider
for example amentity=toilets Which, as you likely know :-), exist both
in free and paid versions. Providing access to a facility for use,
regardless if free or not, is not a shop, not even in OSM.

Simon

> Cheers Martin 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 and space, because even a completely
normal laundromat facility is not a shop. In hindsight it should have
always been amenity=laundry (or similar) but that is a done deal.

While such misnaming might have mattered a decade ago, when people
mainly used raw tags, today the overwhelming number of contributors
never unintentionally see them and the important thing is what is used
as the name of the preset they are using.

PS: I still haven't got myself to use the hopelessly misnamed
shop=agrarian though :-)




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 (yes that
should have probably been amenity=laundry but that's a done deal)  and
add attribute tags for the number of washing machines and dryers?

Simon

Am 09.09.2019 um 01:52 schrieb Joseph Eisenberg:
> Several new and existing property and feature tags for campsites,
> caravan sites, camp pitches, picnic sites and related tourism features
> are now open for voting:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Campsite_properties
>
> Main changes:
>
> - Deprecate booking=* (use reservation=* instead)
> - Deprecate bbq=* (use barbecue_grill=* instead).
>
> There is also a list of new properties and features. These do not yet
> have wiki pages:
>
> - amenity=power_supply
> - amenity=bear_box
> - bear_box=yes/no
> - amenity=greywater_drain
> - greywater_drain=yes/no
> - kitchen=yes/no
> - waste_disposal=yes/no
> - scout=yes/no
>
> See the whole list at
> https://wiki.openstreetmap.org/wiki/Proposed_features/Campsite_properties#Tagging:_List_of_Proposed_Tags_To_Approve
>
> I apologize for including this many tags in the proposal.
>
> However, it appears that they are non-controversial since there were
> no specific negative comments during the RFC, and they are already
> used at least a few times in the database, so I'm proceeding with
> voting for them all together to save everyone time.
>
> But since I think it's not best practice to include so many tags in
> one proposal, I've got a special deal for anyone who objects to one of
> these tags:
>
> Just include a comment with your vote stating which tag you oppose and
> why, and we will consider it "vetoed", and I will bring it up as a
> separate proposal later which can be discussed in more detail.
>
> This could be a comment with a "approve" vote, a "disapprove" vote, or
> an "abstain", depending on how you feel about the rest of the proposed
> tags.
>
> If you missed the previous discussions about these tags, see
> https://wiki.openstreetmap.org/wiki/Proposed_features/Campsite_properties#External_discussions
>
> Here's the link for voting:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Campsite_properties#Voting
>
> -Joseph Eisenberg
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - appointment

[Simon Poole]

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 would have to equate this to  "you have to inquire if it is
>> open")?
>
>
> it may be the same for apps, it isn’t for mappers, “unknown” is an
> imperative for surveying it.

This is -not- supported by the existing documentation
https://wiki.openstreetmap.org/wiki/Key:opening_hours#Summary_syntax


> It may also make a difference for some searching for such features,
> because unknown means you might be lucky and they’ll serve you, by
> appointment means you must not even try if they might be open.
>
That on the other hand might be a useful distinction.

Simon


> I welcome documenting this value, as it is already used with varying
> syntax more than 500 times, so it is clear mappers want
> it: https://taginfo.openstreetmap.org/keys/opening_hours#values
>
> Cheers Martin 
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - appointment

[Simon Poole]

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":
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Opening_hours:_standard_appointment_syntax
>
> Kind regards
> Ruben
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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  > wrote:
>
> Here's a proposal for marking indoor routes within a building
> mapped with Simple Indoor Tagging.
>
> footway=indoor: indoor pedestrian route
> https://wiki.openstreetmap.org/wiki/Proposed_features/footway%3Dindoor
>
> Jeremiah Rose
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 of transportation kind in the the geographical
scope was a mistake, but is a done deed for cycling and hiking. BUT
there is no need to propagate repeating the mistake for every other
transportation mode, lets just stick with local, regional, national and
international these (historically I suspect that the values came from
direct tagging on ways,  lcn=yes and similar).




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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
> I had
> to check which is the correct spelling (“sculptor” FTR ). I suspect
> that's what's happened here.
>
>
>
> I have to admit I couldn't resist and fixed the spelling some of them
> in Europe. While checking the objects I noted some artworks that had
> been mistagged with the craft key. If you check around your area for
> these you'll maybe find similar problems. 
>
> Cheers
> Martin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Multiple tags for one purpose

[Simon Poole]

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 author of "changing_table" and the
> guy who lead it throw the proposal process and also Moderator of the
> discussion and votes. And contacting all the editors was no problem
> and they implemented "changing_table" and deleted "diaper" presets.
> See JSOM, OSMand, Vespucci and also iD. My effort shows that working
> together with different groups works.

A) at least I didn't "delete" the diaper preset.

B) you are confusing the decision that something is too silly to argue
about, with agreement.

>
> I would highly appreciate it when you give me a chance. In real life
> people are revelling their secrets to me because they trust me and I
> give them the feeling of being accepted as they are. It includes my
> talks with people from different worlds. More-Than-One-World Secrets.
> This connection I can try to create also among OSM folks (societies).
>
That is seriously OT.


> Best regards
>
> Sören Reinecke alias Valor Naram
>
>
>  Original Message 
> Subject: Re: [Tagging] Multiple tags for one purpose
> From: Paul Allen
> To: "Tag discussion, strategy and related tools"
> CC:
>
>
>
>
> On Sat, 24 Aug 2019 at 17:06, Valor Naram  > wrote:
>
>
> In my opinion this is a topic we should consider working on
> and creating a wikipage to describe the "defragemtation"
> process in general.
>
>
> Doing so is probably not going to achieve much.  First we need to
> defragment OSM itself.
> It doesn't matter what wonderful tags we come up with here, if
> carto refuses to render them
> then they won't get used.  It doesn't matter what wonderful tags
> we come up with here, if editors
> don't implement them as presets they won't get used.
>
> Carto won't (in general) render a tag unless it's widely used. 
> 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.
>
> There are complications (of course).  Carto (in general) refuses
> to implement aliases, so
> whatever the merits of deprecating landuse=grass in favour of
> landcover=grass, carto will
> refuse to render landcover=grass.  Editors don't (in general) like
> implementing aliases
> either.  So however much we wish to try to fix bad tags, which are
> frequently misused
> because the name or value was a bad choice, it probably won't
> happen.  Some editors
> occasionally decide they'll ignore the list, the wiki, and carto,
> and go their own way
> (sometimes they get their way and sometimes they get a slap on the
> wrist).
>
> So what we need at this stage is not a defragmentation process but
> joined-up thinking
> between the various groups.  I'm not holding my breath on that one.
>
> -- 
> Paul
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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
>>
>> "Indicates the average daily number of nurses available at a health
>> facility"
>
> On 01/08/2019 22:17, Mhairi O'Hara wrote:
> > Voting is now open for the proposed feature staff_count:doctors
> >
> > "Indicates the average daily number of doctors available at a health
> > facility"
>
> Instead of “average daily” how about “whole-time equivalents”? Someone
> who works full time counts as 1. 50% time (“part time”) means 0.5. So
> 2 part time doctors, or 1 full-time doctor, is `staff_count:doctors=1`?
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 (`payment:american_express=no`),
> wouldn't this work for insurance companies? `insurance:vhi=no`, or
> `insurance:health:vhi=no`?

The problem with this, just as with payment, that it creates a
(practically) unbounded list of keys, that rely on being able to do a
search on keys to be discoverable.

Simon


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



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 
> reasoning that natural=tree should only be used for “special” and alone 
> standing trees, so that all other trees which were standing in groups had 
> gotten the cluster tag. Meanwhile the saner approach is to tag special trees 
> with additional tags and accept that natural=tree has no other implications 
> than “a tree”. IMHO it is ok to see denotation=cluster as deprecated.

That is a mischaracterisation of what actually happened. Originally
(pre-mass imports of trees) natural=tree was intended only for notable
trees (as landmarks, or for other reasons) and there was only a small
number of them in the data. The mass-imports without further
qualification lost that semantic information, which led to a longer
conflict trying to undo the damage (which was already hopeless IMHO).
The correct approach would have been to address the problem before the
imports.

Unluckily, not only, but particularly here, it is clear that the lessons
from this specific disaster have not been learnt.

Simon


> Cheers Martin 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 Openstreetmap-Carto
> style to reload the whole planet database before this key can be
> supported for rendering, routing or search applications. Using
> amenity=MRI or healthcare=MRI would be easier for current database
> users to support and it’s shorter for mappers to type.

That applies equally to health_amenity:type, in any case anybody wantig
nto support outlandish keys will be running with hstore enabled.


>
> 2) If you want to add this as a tag to an amenity=hospital, then you
> can’t add both an MRI and a CT scanner, for example, since a key can
> only have one value. 
>
Multi-value keys are in widespread use, and when they represent lists
totally unproblematic.

Simon

PS: waiting for the first posts requiring that the absence of equipment
is taggable.


> So in that case you still need MRI=yes as an addition key to tag on an
> existing facility. I suspect this tagging will be more common than
> mapping the MRI separately, and it certainly will be more common for
> ultrasounds, which are on wheels (casters) usually and can move around
> the hospital.
>
> Joseph
>
> On Fri, Jul 26, 2019 at 4:01 AM Mhairi O'Hara  > wrote:
>
> Hello everyone!
>
> I completely agree with Warin that the *health_amenity:type* tag
> is pretty confusing as to what its referring to. I was trying to
> stay in line with what was proposed previously, but in retrospect
> it would be better to move away from previous efforts and vote in
> a tag that is straight forward and easy to understand (says what
> it is).
>
> The main aim for the tag is to encapsulate that its related to
> health equipment, so how about *healthcare:equipment*?
>
> Kind regards,
>
> Mhairi
>
> On Sun, Jul 14, 2019 at 4:43 PM Warin <61sundow...@gmail.com
> > wrote:
>
> This is about the equipment available? 
>
> Using the principle of 'say what it is' ...
>
> medical_equipment=MRI ??? Assuming the tag is for equipment.
>
> Calling the key health_amenity:type "in use" is a stretch - 40
> uses .. and most of these are for first aid kits!
> The next most popular is "scales".
> Fist aid kits have the tag emergency=first_aid_kit ... which
> is more popular (170) despite it being a "draft".
>
> No, I don't think is is "in use" nor has it been used in a
> sensible way. Probably because "type" can mean anything.
>
> health_facility:type has the same problem, despite being more
> popular, uses are for
> dispensary
> office
> clinic
> hospital
> etc
>
>
> On 14/07/19 23:18, François Lacombe wrote:
>> Hi Mark,
>>
>> I agree with your choice to specifiy which service are
>> available in a given facility.
>> This doesn't require to add :type in the name of the key.
>> Such suffixe don't bring any information.
>> Your proposal would be way better if you use
>> health_amenit=MRI at least instead
>>
>> All the best
>>
>> François
>>
>> Le jeu. 11 juil. 2019 à 21:10, Mark Herringer
>> mailto:m...@healthsites.io>> a écrit :
>>
>> The intention of the tag is to specify physical equipment
>> (health_amenity:type=MRI) and should be used in
>> conjunction with amenity=clinic to show that the health
>> facility contains that specialised equipment. This will
>> enable mappers say that "this clinic contains an MRI"
>> ᐧ
>>
>> On Thu, 20 Jun 2019 at 08:15, Joseph Eisenberg
>> > > wrote:
>>
>> 4) health_amenity:type
>>
>> I think the key "healthcare" should be used instead
>> of the new key
>> health_amenity:type". If it's necessary to tag an MRI
>> facility
>> separately, then create a tag like "healthcare=mri".
>>
>>  However, it may be more useful to use a tag like
>> "mri=yes" on the
>> main amenity=hospital or the radiology department
>> within the medical
>> centre - this tag would let mappers say that "this
>> hospital contains
>> an MRI" without requiring mappers to precisely locate
>> the MRI
>> equipment within the building. This would also make
>> it easier for
>> database users: they can just check for
>> 

Re: [Tagging] Maxweight wiki page changes

[Simon Poole]

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 and merging it, and so you are not commenting on just
random third party wiki edits.

Am 03.07.2019 um 12:52 schrieb Tobias Zwick:
> Reviewed it. That is some impressive work, thank you for this!
>
> A few remarks:
>
> 1. Maxweight
>
> 1.1 At the examples: for max empty weight, I propose the key maxemptyweight. 
> It suggests itself.
>
> 1.2 At the examples: Conditionals should maybe better be catch-all, so i.e. 
> axles>=3 instead of axles=3
>
> 2. Maxweightrating:
>
> 2.1 At the examples, Poland: This sign is actually an access restriction for 
> all HGVs: hgv=no. By definition in EU laws and most other countries, a heavy 
> goods vehicle is a goods vehicle with a GVWR of 3.5t and above. See the wiki 
> page for Key:hgv for a longer explanation.
>
> 3. Maxaxleload mentions that weight in USA must always be given in short tons 
> while the maxweight article also mentions pounds. Same with the article about 
> maxbogieweight.
>
> 4. Maxbogieweight in Romania: I'd say a tri-axle is still a bogie.
>
> Tobias 
>
>
> On July 3, 2019 9:43:12 AM GMT+01:00, Mateusz Konieczny 
>  wrote:
>> There were recently significant changes at OSM Wiki page about
>> maxweight tag
>> and related tags. Review is welcomed.
>>
>> See
>> https://wiki.openstreetmap.org/wiki/Key:maxweight
>>  - major changes
>> included fixing mistakes
>> in examples, adding additional examples, reformatting, documenting how
>> object without max weight
>> sign may be tagged
>>
>> https://wiki.openstreetmap.org/wiki/Key:maxweightrating
>>  - page itself
>> is quite new. Recent changes
>> included reformatting and new examples
>>
>> https://wiki.openstreetmap.org/wiki/Key:maxaxleload
>>  - smaller
>> changes, but for completeness:
>> fixing mistake and additional examples
>>
>> Again, review is welcomed!
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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.

Am 25.06.2019 um 10:27 schrieb marc marc:
> Le 25.06.19 à 10:16, Ulrich Lamm a écrit :
>> the ban is totally injust.
> add injust=maybe
> or
> find a better place to talk about not-related-to-tags stuff
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 affect we could get rid of the web irc UI
which oftc doesn't like). Both likely not gigantic tasks, but nobody has
stepped up to date.

Simon

PS: HW is likely not to be an issue.

Am 23.06.2019 um 12:19 schrieb bkil:
> I'm thinking more along the lines of:
> https://en.wikipedia.org/wiki/Matrix_(communication_protocol)#Bridges
> https://en.wikipedia.org/wiki/Friendica#Features
> But we're still missing a few. It would be best if we had a single
> unified platform (or one for realtime, and one for non-realtime use
> cases). Partitioning could still be done using labels/categories
> within the platform.
>
> On Sat, Jun 22, 2019 at 10:52 PM marc marc  wrote:
>> Le 22.06.19 à 10:31, bkil a écrit :
>>> I wonder why nobody has created a gateway
>>> to merge all discussions
>> nabble.com/ do the job (but you can only merge ml/forum only
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

Am 02.06.2019 um 17:36 schrieb osm.tagg...@thorsten.engler.id.au:
> I've just checked the history, and as far as I can tell, there has been a 
> grand total of just 15 proposals put to voting since the beginning of the 
> year (5 months, so 3 per month on avg.)

There were ~16 new proposals last month, which compared to 3, shows just
why I'm making this suggestion.

Simon

 

>
> Also, even with all the noise, there have been only about 28 messages per day 
> on avg, which is less then most other mailing lists and forums I follow.
>
> I agree that there has been some 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
>> To: Tag discussion, strategy and related tools
>> 
>> Subject: [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, potentially commenting on its talk page and
>> here, the increase in noise has led to even a cursory examination of
>> proposals for obvious flaws (see the police proposal) not being
>> possible at the current rate of a new proposal every second day.
>>
>> In the interest of keeping the list at least half usable, I would
>> suggest that we all, starting now, voluntarily submit to:
>>
>> - not posting more than 30 times per month (the 30 comes from the
>> WMF mailing lists, where it seems to work quite well)
>>
>> - not more than one proposal per person per month
>>
>> - not more than 4 new proposals per month in total
>>
>> Simon
>>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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't.
>
>
> Really?  You looked inside my head and determined that I do not
> understand your frustration.
> And here I was thinking that I merely disagreed with your proposed
> solution.  That just goes to
> show how stupid I am, right?
>
> There is just no way the community can handle a dozen or more
> proposals per month in any reasonable fashion,
>
> That's an interesting assertion.  I'm not convinced the evidence backs
> it up, but I'll assume
> (for the sake of argument) that you're right.  So now what?  We refuse
> to deal with the 13th
> proposal in a month so the proposer invents an ill-conceived tag and
> uses it.  Until and
> unless you can put a mechanism in place that prevents people inventing
> tags and using
> them without discussing them on the list first, this is not a good
> idea.  Hint: I use `12 of my
> 30 posts/month proposing whimsical tags, so that the tag I really want
> to use is not
> subject to discussion so I'm free to use it anyway.

As Frederik has already pointed out, a proposal and the perhaps the
following "stamp of approval" is not necessary for using a tag, some
documentation would be nice but not required. So nothing in my
suggestion limits which tags can be used, it just rate limits the influx
of proposals that actually want attention, so they can actually get it.

Simon


> essentially it is just gaming the system in another way than
> wikifiddiling.
>
> It appears you believe people are deliberately making proposals to
> game the system.  I'm
> far from convinced that is the case.  But if you're right about people
> acting in bad faith, I'd
> already thought of two ways people can game your proposal before you
> replied to me, and I
> wasn't even putting any effort into trying to find flaws like that. 
> Your proposal won't stop people
> gaming the system (if anybody actually is gaming the system), it will
> just change the tactics.
>
> -- 
> Paul
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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:
>
>
> [...]
>
> I don't doubt your frustration or your good intentions, but it seems
> possible that this thread
> will generate a large volume of increasingly heated responses, making
> the list even more
> annoying (at least until it all dies down).  Not your intention, but a
> possible outcome.
>
> Others have already mentioned problems with your suggestions, and no
> doubt many
> more will do so.  I'm in broad agreement with those objections.
>
> As I already said, I understand your frustration. 

No, obviously you don't.

There is just no way the community can handle a dozen or more proposals
per month in any reasonable fashion, essentially it is just gaming the
system in another way than wikifiddiling. BTW I've used threaded mail
clients for a couple of decades and that is not the problem either or
the volume that the bike sheding which is to be expected due to the
subject matter tends to produce

Simon

> The best solution is a mail client capable of
> filtering out threads or people you feel are not worth your
> attention.  It's not an ideal solution
> because you will miss things that way - somebody raises a good point
> in an ignored thread
> or somebody you ignored because you almost always disagree with that
> person says
> something worth while.
>
> Downsides of filtering: you may still see snippets of somebody you've
> blacklisted when
> another person quotes them.  You may see an ignored thread reappear
> because of
> people not threading their replies correctly.
>
> Upside of filtering: you may still see the few good contributions from
> somebody you've
> blacklisted when that person gets quoted by somebody else.
>
> -- 
> Paul
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

I'm suggesting that everybody is grown up enough to self limit themselves. 
Outside of that, when in doubt a quick look at the months archive is all that 
is really needed.

Simon

Am 2. Juni 2019 11:11:36 MESZ schrieb Jo :
>Who's going to keep the tally? Maybe we need an actual tool to help
>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 Simon Poole  wrote:
>
>> 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, potentially commenting on its talk page and here, the
>increase
>> in noise has led to even a cursory examination of proposals for
>obvious
>> flaws (see the police proposal) not being possible at the current
>rate
>> of a new proposal every second day.
>>
>> In the interest of keeping the list at least half usable, I would
>> suggest that we all, starting now, voluntarily submit to:
>>
>> - not posting more than 30 times per month (the 30 comes from the WMF
>> mailing lists, where it seems to work quite well)
>>
>> - not more than one proposal per person per month
>>
>> - not more than 4 new proposals per month in total
>>
>> Simon
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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, potentially commenting on its talk page and here, the increase
in noise has led to even a cursory examination of proposals for obvious
flaws (see the police proposal) not being possible at the current rate
of a new proposal every second day.

In the interest of keeping the list at least half usable, I would
suggest that we all, starting now, voluntarily submit to:

- not posting more than 30 times per month (the 30 comes from the WMF
mailing lists, where it seems to work quite well)

- not more than one proposal per person per month

- not more than 4 new proposals per month in total

Simon




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Underground Mall entrances?

[Simon Poole]

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 (or under) laying objects.

level is the tag used to indicate position within/relative to a
buildings floors. 

>
> But how should we specify the location of an entrance to the underground mall?
>
> There is an amenity=parking_entrance tag for the entrance of an
> underground (or aboveground) parking structure, which allows routing
> and rendering applications to show this location specifically.
>
> It could be useful to map the location of the mall entrances, both for
> underground malls and large above-ground malls, so that the main mall
> entrances can be located separately from all the individual shop
> entrances. T

If you want to go to this level of detail, you should be mappign the
structure that the door is in too.


>
> he tag indoor=yes can be used with entrance=yes to show that this door
> is within the mall, but there isn't a specific way to show the main
> entrance/exit from the whole shopping centre, when the outer way of
> the area doesn't intersect with the entrance=yes node.
>
> This would be common with underground malls, where the entrance may be
> inside of, or even outside of, the polygon that outlines the area of
> the mall, because the escalators or stairs are usually not right at
> the boundary.
>
> Would something like entrance=mall or mall=entrance work?
>
> Or do we need a subtag for entrance=yes?
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

Am 25.05.2019 um 12:48 schrieb osm.tagg...@thorsten.engler.id.au:
>
> Yes, but that’s not the point.
>
>  
>
> The presence or absence of markings do not change the fundamental
> operating principle of the crossing (go only when it’s green).
>
>  
>
> The strips shown in the image you linked do not mean that pedestrians
> have priority here and can just walk across any time, no matter what
> the signal says.
>
>  
>
> The crossing would work exactly the same with and without these strips.
>
Not if the lights are not running/blinking (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-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
> all over central Europe (as pointed out in one of the contributions a
> couple of 100 postings back, they will typically control the vehicle
> traffic too). Random example
> https://www.mapillary.com/app/user/sp8962de?menu=false=photo=47.4040085=8.3944280902=15.17281376123384=true=zL2pXJc6T_RffQheFsdbYA
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 all
over central Europe (as pointed out in one of the contributions a couple
of 100 postings back, they will typically control the vehicle traffic
too). Random example
https://www.mapillary.com/app/user/sp8962de?menu=false=photo=47.4040085=8.3944280902=15.17281376123384=true=zL2pXJc6T_RffQheFsdbYA



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] solving iD conflict

[Simon Poole]

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
>>> financial conflict of interest to be highly inappropriate. [...]
>> Please don't put words into my mouth here - i have said what i said and
>> not what you have read into that.
> Forgive me for drawing what appeared to be an obvious inference. If
> you don't want to imply that the project enjoys some sort of unfair
> privilege, or is subject to some sort of unfair influence, by reason
> of its financial support, then why bring it up at all - particularly
> the anonymity? Lost of open-source software projects have received
> donations to support development. Some donors have wished to remain
> anonymous. Mentioning such support in the context of other unfair
> advantages that you see iD as enjoying is highly suggestive, whether
> you intended it or not.

Actually nearly all of the above is true though it is debatable if
having deeper pockets to draw upon is "unfair", but it just isn't a
"conflict of interest". The iD developers and there employers have
neither formal (as in the law) or informal (as in having committed to
any specific behaviour) obligations towards the OSMF and the OSM
community, there simply can't be a CoI if you don't have interests that
conflict.

Is the situation massively intransparent? Sure and I don't think
comparing with random other OSS projects is warranted as they typically
don't exert control over the content produced in a comparable fashion
(even comparing say to WPs visual editor where undoutably heads would
already be rolling in a similar situation).

Simon


> ___
> 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] solving iD conflict (was: pointlessly inflamatory title)

[Simon Poole]

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 list (as it often is)
> is to gripe about how the iD editor isn't listening to this mailing
> list (and sometimes on Github issues). I've listed some reasons as to
> why someone might not listen to this mailing list. Reasons that I've
> heard echoed many times in various venues...
>
I think if you investigate, you will find that invariably such
complaints (including the predictably, invariably going to be
used,"toxic"), originate with people that didn't get their way, or
associates of them ("didn't get their way" as in: there was a
substantial body of opinions that disagreed with what ever they were
proposing).

If you are addressing a very diverse group, disagreement is the name of
the game. People that can't with live that will tend to gyrate towards
more controlled and selective environments, particularly if they can
control the discourse as they can do for example on a github repo, or a
slack channel. Not to mention that on any of the larger more diverse
forums, that is any of the international, and topical mailing lists,
forums, IRC channels, you will have a large selection of different
discussion cultures, and will experience everything from people directly
calling a spade a spade, to criticism being packaged in multiple layers
of cotton wool.

Simon

PS: I think you owe us proof of this rather extraordinary claim > - You
will probably be insulted at some point, potentially sworn at.

> On Thu, May 23, 2019 at 3:05 PM Tobias Zwick  > wrote:
>
> These are some valid points, and I also have some input to that,
> but are you sure you want to discuss this on the tagging ML? 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 ;-)
>
> Tobias
>
> On 23/05/2019 21:58, Nick Bolten wrote:
> >> Yes, it would be great. There is plenty of negative emotion on
> both sides and it would be great to reverse this (for example
> title that I used was frankly stupid what I realized after sending
> the message).
> >
> > OSM needs an alternative for community tagging discussions
> outside of these mailing lists. Ones that people will actually use
> and that have a reasonable, community-oriented code of conduct. I
> have talked to 10X more people about my `crossing` proposals
> outside of this mailing list (in-person, personal emails, slack,
> etc.) and the differences could not be more stark:
> >
> > # My experiences with OSMers in other contexts:
> > - Very friendly, all focused on making maps better, highly
> motivated to donate their time to help others via the map.
> > - Disagreements are pleasant. Both sides acknowledge the other
> point of view and usually come around to a compromise.
> > - There is interest in knowing more: lots of questions back and
> forth.
> > - Objections are qualified and polite.
> > - 10s-100s of people giving feedback on a single idea.
> >
> > # My experience with this mailing list:
> > - Quick to exasperate.
> > - You will be assumed to be coming to the table in bad faith.
> > - You will probably be insulted at some point, potentially sworn at.
> > - The same 8 or so people respond to posts out of a community of
> tens of thousands of people, companies, non-profits, etc.
> > - The odd situation of absolute certainty in completely
> incompatible opinions from those that do respond.
> > - Difficult for people to discover. How do we know that the
> opinions shared here are in any way representative of the
> community, given that so few discover + participate in it?
> > - Difficult to filter for relevance. Have to set up email
> filters and/or specialized search queries.
> > - Zero real synchronization with OSM editors, the only way
> people add data to the map. Blame doled out everywhere, but very
> little in the way of collaboration, no real venue for doing so
> (see previous bullet points).
> >
> > Focusing on the idea of being an "arbiter", does that sound like
> a good way to figure out which tags are good/acceptable?
> >
> > When I was mentoring a group of students a few years ago,
> several were offended by the condescending and insulting responses
> they received on this mailing list, all because they suggested
> making a coherent way of combining existing tags into a pedestrian
> schema and doing a carefully-vetted import. The import was so
> carefully-vetted that we later realized it wasn't even really 

Re: [Tagging] Wiki changes for police tag

[Simon Poole]

Am 18.05.2019 um 11:44 schrieb Jan S:
> Interesting point... I'd suggest that it is a top-level tag itself.
> Otherwise you'd have to tag buildings as building=* and police=*,
> which I find an unnecessary duplication that might even result in
> contradictory tags.

I think you 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 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 23:03 schrieb Jan S:
>> Hi everyone,
>>
>> I've created the pages
>> https://wiki.openstreetmap.org/wiki/Key:police and subpages for
>> values police=barracks, police=car_pound, police=car_repair,
>> police=checkpoint, police=detention, police=naval_base,
>> police=offices, police=range, police=storage and police=training
>> area, as well as the generic police=yes.
>>
>> All this in accordance with the approved proposal for key:police.
>>
>> Best, Jan
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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
> different country from you is
> closed because it follows a different definition of Easter from your
> location."  Not so easy
> for Ramadan defined by visual observation.
> ...

Evaluation of opening hours values already depends on location and lots
of configuration for the PH tag (and in principle for the SH one too).
So this wouldn't be introducing anything new. See
https://github.com/opening-hours/opening_hours.js#holidays



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 of "context" value to help in the later (for
example a time zone value as has been suggested previously)  could
potentially work.

Simon

Am 18.05.2019 um 12:34 schrieb Phake Nick:
> That doesn't seems to solve the problem that would occur. For
> instance, how to represent the first Sunday (a feature in Gregorian
> calendar) after Chinese traditional ceremony X (a feature in Chinese
> traditional calendar) in the opening time syntax, if they're split up
> for "simplicity"? What about when the opening time also cover
> non-holiday festivals that only occurs according to either calendars?
>
> On 2019-05-18 Sat 04:50, Paul Allen  > wrote:
>
> Problem of splitting: what if a mapper gives the opening times in
> both calendar_X and calendar_Y
> and they disagree?  Consumers will have to have rules like: in
> country_Z use calendar_X if given,
> otherwise use standard opening_hours if given, otherwise use
> calendar_Y if given, otherwise
> pick at random from what is left.
>
> -- 
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki changes for police tag

[Simon Poole]

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 23:03 schrieb Jan S:
> Hi everyone,
>
> I've created the pages https://wiki.openstreetmap.org/wiki/Key:police
> and subpages for values police=barracks, police=car_pound,
> police=car_repair, police=checkpoint, police=detention,
> police=naval_base, police=offices, police=range, police=storage and
> police=training area, as well as the generic police=yes.
>
> All this in accordance with the approved proposal for key:police.
>
> Best, Jan
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC - Connectivity

[Simon Poole]

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 turn:lanes fails to
> store all of the necessary information in many junctions.  Multi-lane
> roundabouts, single point urban interchanges, 5 way intersections with
> divided roads, and other cases are all too complex for turn:lanes to
> handle.
>
> Because of this, I have created a proposal for a simple type of
> from-via-to relation that would provide information about how lanes in
> the "from" way connect to those in the "to" way at any point where it
> isn't clear.  These relations are very similar to turn restrictions,
> and like turn restrictions, wont be needed in most intersections.  
>
> The relation would also be able to store the same information as could
> have been possible with transit:lanes, just without the many
> maintenance issues that came that system.
>
>
> https://wiki.osm.org/wiki/Proposed_features/Connectivity
>
>
> All feedback on how to potentially improve the proposal would be
> highly appreciated!
>
> Thanks, 
> Leif Rasmussen
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Expand the key:opening_hours

[Simon Poole]

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 in a local context as the location they
> apply to is always known), so a time zone indicator would be only
> needed
> in the cases that require different processing, the question is if
> that
> is common enough to justify the additional complication.
>
> The three most prominent area that are still using the calendar
> nowadays are China, Korea, Vietnam. Each of them have their own
> version of this lunar calendar with the most notable difference being
> the meridian used to create the calendar. So that once in a few years
> you could see reports saying that the lunar calendar and the festival
> that depends on it are not correct on some software.
>
> Let's say you represent the Lunar New Year as L01 01. The software can
> assume it mean Chinese New Year in China, Vietnamese New Year in
> Vietnam, and Korean New Year in Korea. So far so good. But then these
> festivals aren't just celebrated within these three countries. Places
> like Thailand, Indonesia, Japan, Australia, America, and many other
> countries around the world all have different events that would take
> place for the Lunar New Year. Sometimes they're commercial events that
> are currently catering specifically to Chinese New Year. Sometimes
> they are diaspora population that celebrate the festival on the same
> day as their parent countries. You cannot know which exact day it's
> referring to without referring to the timezone being used to calculate
> the calendar, and at least it need to specify
> Korean/Chinese/Vietnamese version and that is assuming the region will
> not create any new timezone in the future, like how time changes
> related to the Vietnamese war caused the North Vietnam and South
> Vietnam celebrated the new year at different date back then and
> resulted in some military advantages.

That's all fine and dandy, but the OSM opening_hours tags is for the
opening hours of facilities and similar, not a general purpose event
description facility. So I would expect that a shop in AUS that is
closed on a Chinese holiday to indicate that in a local Gregorian
calendar fashion.

>
> One might think it'd be easier to add CNY/KNY/VNY into the variable
> holiday separately like easter instead, but there are a number of
> other events that're celebrated based on local lunar calendar and is
> celebrated at more places than those aforementioned countries, like
> Confucius birthday, mid-autumn festival, double nine festival, and so
> on. If calendar-specific version of all these holidays are all getting
> their own values as variable-holiday then there would be too many of them.
>
> And there also other scenario that timezone value is useful, for
> instance iirc Fiji decided that the country will implement DST but the
> school system operation time will not follow the transition. Or in
> places like Xinjiang or West Bank where there are two different
> timezones used by different population living in same area.
>
>
> - Summer and winter solstice can be, as far as I can see, modelled as
> additional variable_date values (currently only "easter" is
> defined), I
> would avoid qualifying them with months as again, that require parser
> changes that will cause issues.
>
>
> Except other solar terms are still used. For example March equinox and
> September equinox are national holiday in Japan. Setsubun celebration
> in Japan is mainly a day before first solar term in February but also
> a day before first solar term in May, August, November. Qing Ming
> (mainly China, Korea, etc.) is the first solar term in April.
>
>
> - Lunar months: are there any common names for these instead of just
> numbering? And how are the "leap" variants supposed to be different?
>
> Simon
>
>
> It is usually just numbering, but in Chinese there are nickname for
> the 11th and 12th month, while in Japanese there are nickname for all
> the months. Consider that those nick name are less popular,
> regional-specific and language-specific, it seems like it would be a
> bad idea to name them after the months.
> The "leap" version are for when a year have 13 lunar months. Instead
> of naming the additional month the 13th month, various criteria are
> used to select one of those thirteen months, and then name it as the
> "leap" version of the previous month. There are on average about 7
> years with leap month in every 19 years.
>
>
The whole reason that t

Re: [Tagging] Expand the key:opening_hours

[Simon Poole]

Some more comments:

- the OH values are currently always evaluated in the local time zone
(or to go even a bit further in a local context as the location they
apply to is always known), so a time zone indicator would be only needed
in the cases that require different processing, the question is if that
is common enough to justify the additional complication.

- Summer and winter solstice can be, as far as I can see, modelled as
additional variable_date values (currently only "easter" is defined), I
would avoid qualifying them with months as again, that require parser
changes that will cause issues.

- Lunar months: are there any common names for these instead of just
numbering? And how are the "leap" variants supposed to be different?

Simon

Am 14.03.2019 um 02:03 schrieb Phake Nick:
> Separating it from the current system might have the advantage that it
> will not need to use the same syntax to support all regional specific
> methods of day counting and time counting at once, but even after
> separated it will still need to support the full set of current
> opening_time specification in addition to those regional
> specifications.
>
> 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.openstreetmap.org/wiki/Conditional_restrictions . While I
>>> haven't looked at in detail your proposal for a timezone extension
>>> might have difficulties with that.
>>>
>>> Am 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 ones are rather broken, adding more stuff is
>>>> definitely not going to improve things.
>>>>
>>>> That said, there are one or two places where extensions would be low
>>>> impact (extra holiday and variable_date  values for example). However in
>>>> any case I would suggest you familiarize yourself with the actual
>>>> grammar
>>>> https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification
>>>> first , in particular your proposal begins with a couple of non-starters
>>>> that conflict directly with the existing specification.
>>>>
>>>> Simon
>>>>
>>>> Am 13.03.2019 um 19:52 schrieb Phake Nick:
>>>>> I found that the current way of mapping opening time of features in
>>>>> OSM map are too limiting, and the opening time of some features cannot
>>>>> be properly represented with only the current syntax, therefore I have
>>>>> written a brief idea about how the syntax in key opening_hours could
>>>>> have been expanded to match more different needs at the article's talk
>>>>> page. 
>>>>> Seehttps://wiki.openstreetmap.org/wiki/Talk:Key:opening_hours#Proposed_extension_to_supported_syntax_in_the_page.
>>>>> . It would be nice if these features can be added into the scheme so
>>>>> that relevant featurs opening days and time can be represented by the
>>>>> scheme directly instead of via text description and external link.
>>>>>
>>>>> The most significant part of what I would like to see are support for
>>>>> solar term(節氣/节气/節気/절기/Tiết khí) and (East Asia) lunar (lunisolar)
>>>>> calendar(舊曆/旧历/旧暦/음력/Nông lịch). And because the calculation of both
>>>>> are dependent on timezone and then when some countries celebrate these
>>>>> festivals they use the calendar that is not based on their own
>>>>> country's time but use the Chinese time (or time of other countries
>>>>> for overseas diaspora of them) so I have also added a proposal to
>>>>> support timezone specification in the scheme which is also desired by
>>>>> some other users on the talk page. Note that the scheme I proposed to
>>>>> express solar term and lunar month representation wasn't actually that
>>>>> much intuitive but I believe it have an advantage that it's more
>>>>> internationalized and thus providing a common way of tagging features
>>>>> across different regions that use the calendar.
>>>>>
>>>>> Additionally, I have also written in the proposal that I would like to
>>>>>

Re: [Tagging] Expand the key:opening_hours

[Simon Poole]

Just a PS: any grammar extension need to be compatible with the use of
OH strings in conditional restrictions too, see
https://wiki.openstreetmap.org/wiki/Conditional_restrictions . While I
haven't looked at in detail your proposal for a timezone extension might
have difficulties with that.

Am 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 ones are rather broken, adding more stuff is
> definitely not going to improve things.
>
> That said, there are one or two places where extensions would be low
> impact (extra holiday and variable_date  values for example). However in
> any case I would suggest you familiarize yourself with the actual
> grammar
> https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification
> first , in particular your proposal begins with a couple of non-starters
> that conflict directly with the existing specification.
>
> Simon
>
> Am 13.03.2019 um 19:52 schrieb Phake Nick:
>> I found that the current way of mapping opening time of features in
>> OSM map are too limiting, and the opening time of some features cannot
>> be properly represented with only the current syntax, therefore I have
>> written a brief idea about how the syntax in key opening_hours could
>> have been expanded to match more different needs at the article's talk
>> page. See 
>> https://wiki.openstreetmap.org/wiki/Talk:Key:opening_hours#Proposed_extension_to_supported_syntax_in_the_page.
>> . It would be nice if these features can be added into the scheme so
>> that relevant featurs opening days and time can be represented by the
>> scheme directly instead of via text description and external link.
>>
>> The most significant part of what I would like to see are support for
>> solar term(節氣/节气/節気/절기/Tiết khí) and (East Asia) lunar (lunisolar)
>> calendar(舊曆/旧历/旧暦/음력/Nông lịch). And because the calculation of both
>> are dependent on timezone and then when some countries celebrate these
>> festivals they use the calendar that is not based on their own
>> country's time but use the Chinese time (or time of other countries
>> for overseas diaspora of them) so I have also added a proposal to
>> support timezone specification in the scheme which is also desired by
>> some other users on the talk page. Note that the scheme I proposed to
>> express solar term and lunar month representation wasn't actually that
>> much intuitive but I believe it have an advantage that it's more
>> internationalized and thus providing a common way of tagging features
>> across different regions that use the calendar.
>>
>> Additionally, I have also written in the proposal that I would like to
>> see additional supported values for bank holidays, offset in term of
>> number of weeks, and also support for timestamp beyond 24 hours in the
>> scheme. Expressing time beyond 24 hours can be especially meaningful
>> when the operator of those features decided to release their time this
>> way and it can reduce error when inputing or transporting data into
>> OSM as it is not uncommon for people to forget properly converting
>> dates when they are asked to change the time format back to 00-23h
>> format.
>>
>> And while it seems like the de facto standard, I would also like to
>> see the formalization of the handling of time range representation
>> like Su 23:00-07:00 that in such syntax the 07:00 is referring to
>> 07:00 on the next day.
>>
>> Any thought on the proposal?
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Expand the key:opening_hours

[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 ones are rather broken, adding more stuff is
definitely not going to improve things.

That said, there are one or two places where extensions would be low
impact (extra holiday and variable_date  values for example). However in
any case I would suggest you familiarize yourself with the actual
grammar
https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification
first , in particular your proposal begins with a couple of non-starters
that conflict directly with the existing specification.

Simon

Am 13.03.2019 um 19:52 schrieb Phake Nick:
> I found that the current way of mapping opening time of features in
> OSM map are too limiting, and the opening time of some features cannot
> be properly represented with only the current syntax, therefore I have
> written a brief idea about how the syntax in key opening_hours could
> have been expanded to match more different needs at the article's talk
> page. See 
> https://wiki.openstreetmap.org/wiki/Talk:Key:opening_hours#Proposed_extension_to_supported_syntax_in_the_page.
> . It would be nice if these features can be added into the scheme so
> that relevant featurs opening days and time can be represented by the
> scheme directly instead of via text description and external link.
>
> The most significant part of what I would like to see are support for
> solar term(節氣/节气/節気/절기/Tiết khí) and (East Asia) lunar (lunisolar)
> calendar(舊曆/旧历/旧暦/음력/Nông lịch). And because the calculation of both
> are dependent on timezone and then when some countries celebrate these
> festivals they use the calendar that is not based on their own
> country's time but use the Chinese time (or time of other countries
> for overseas diaspora of them) so I have also added a proposal to
> support timezone specification in the scheme which is also desired by
> some other users on the talk page. Note that the scheme I proposed to
> express solar term and lunar month representation wasn't actually that
> much intuitive but I believe it have an advantage that it's more
> internationalized and thus providing a common way of tagging features
> across different regions that use the calendar.
>
> Additionally, I have also written in the proposal that I would like to
> see additional supported values for bank holidays, offset in term of
> number of weeks, and also support for timestamp beyond 24 hours in the
> scheme. Expressing time beyond 24 hours can be especially meaningful
> when the operator of those features decided to release their time this
> way and it can reduce error when inputing or transporting data into
> OSM as it is not uncommon for people to forget properly converting
> dates when they are asked to change the time format back to 00-23h
> format.
>
> And while it seems like the de facto standard, I would also like to
> see the formalization of the handling of time range representation
> like Su 23:00-07:00 that in such syntax the 07:00 is referring to
> 07:00 on the next day.
>
> Any thought on the proposal?
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Micronations

[Simon Poole]

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 18:28:35 MEZ schrieb ael via Tagging 
:
>On Sat, Feb 09, 2019 at 06:20:11PM +1100, Warin wrote:
>> On 09/02/19 16:18, Mark Wagner wrote:
>> > On Sat, 9 Feb 2019 10:54:16 +1000
>> > Graeme Fitzpatrick  wrote:
>> > 
>> > >
>https://www.openstreetmap.org/way/653287455#map=15/38.0034/-87.6183
>> 
>> In this case they have been mapped as a 'residential area' with that
>name ...
>> The basic question is ... is that area residential?
>
>But note the user name: it does suggest vandalism.
>
>ael
>
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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:
>
> [...] addr tags are for postal addresses I don't think using them as a
> level name/ref makes very much sense outside of that very narrow
> application.
>
>
> I rechecked the two main OSM Wiki pages[1][2] on addr:*=* tags and
> addresses in general and there is no indication there that such tags
> are only intended to encode postal addresses (aside from the specific
> addr:postcode=* tag). Personally, I use addr:*=* tags in any scenario
> where addresses can be used, such as in contact/location addresses
> which is used when the general public (and not just the
> postman/mailman) wants to go to an office, shop, or an establishment.
> For example, the Consulate-General of Japan in Hong Kong lists their
> location where they can be reached[3] as "46-47/F, One Exchange
> Square, 8 Connaught Place, Central, Hong Kong". I could then encode
> this as:
>
> addr:floor=46-47/F
> addr:housename=One Exchange Square
> addr:housenumber=8
> addr:street=Connaught Place
> addr:place=Central (tag probably unnecessary if Central is already a
> boundary)
> addr:city=Hong Kong (probably unnecessary since HK already has a boundary)
>
> As for level=*, I don't know whether this building skips any floor
> numbers (4th? 14th? 24th? etc.) so I would hold off on tagging level=*
> until I get to see their elevator buttons.
>
> [1] https://wiki.openstreetmap.org/wiki/Key:addr
> [2] https://wiki.openstreetmap.org/wiki/Addresses
> [3] https://www.hk.emb-japan.go.jp/itpr_en/opentime.html
>
> ~Eugene
>  
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 joe-casual-data-consumer to get layering right. 
With the current scheme that is a no-brainer even if there are
discrepancies between actual numbering of the floors and what is being
used in OSM.

Simon

PS: addr tags are for postal addresses I don't think using them as a
level name/ref makes very much sense outside of that very narrow
application.




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] service

[Simon Poole]

No magic, the preset has curated values for the subtags (which is
naturally possible in iD too) most of them have historically been
gleaned from the wiki or from actual use.  The upside and the downside
of this is that they are curated, so there is always a certain lag
between a value being used 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 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 thousand uses is not “established tagging practice”.  And I doubt 
>>> that that usage was ever discussed here or proposed either.  If it was, I 
>>> missed the proposal where someone said “lets put tyres in a tag already 
>>> used 3 million times for something else”.  My “no” vote on such a thing 
>>> would not have mattered anyway.
>>>
>>> ...
>> This is not a given, your problem exists just as a consequence of iD
>> retrieving tag values from taginfo and how iD presets are designed.
>> Everything else (as in any other editor) definitely doesn't have an
>> issue with sub-tag keys using the same name as there is more than enough
>> context to be able to differentiate the different usages. 
> How does Vespucci work around this?
> Do you:
> - just build in lists of what all the acceptable values are that people are 
> allowed to enter in different contexts?
> - or let people type anything but expect them to already know what the good 
> values are from wiki research?
> - or just don’t support the `service=` key in some contexts?
> - or something else?
>
> (skipping the rest of the email about `sells=`.. it’s way off topic)
>
> Thanks, Bryan
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Facts and opinions

[Simon Poole]

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 you just select an option,
but the conventional tag - value UI supports lists).


> It is also simpler for data consumers, and as long as you want to
> distinguish only yes/no you could get along with just one bit for storage.
>
That is nonsense as you have to store the key string in some form. In
practical terms any database will use a key-value store for such tags
with a number of associated issues.

Simon

>
> Cheers, Martin 
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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
> default, sold in this type of thing, but aren't here. Is there a
> standard way to do that with semicolon'ed values?
>
You don't,  just as you wouldn't set the other 23 electronic purses
values to "no" for a shop that only accepts one specific type (to use
the granddaddy of the nonsense, the payment scheme).

I really don't think you can extrapolate from it making sense requiring
to be able to set "no" for individual overall attributes of an object
(say oneway=no) to long lists of goods and services for which in
practical terms nobody is going to enumerate all possible values and set
them to "no" if they are not offered at the facility.

Simon





signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Facts and opinions

[Simon Poole]

Inconsistent tagging is inconsistent tagging, don't think that is really
relevant for this discussion, inconsistent tagging schemes however are
on topic.

I'm not convinced that we really want to model such a level of detail in
the first place, but using a small set of common keys for facilities
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>>:
>
> To hypothesize on some of the stuff floating around, obviously
> there is
> a desire to document exactly what kind of stuff a shop sells, so
> people
> have proposed stuff like
>
> motorcycle:tyres=yes
>
> service:tyres:car=yes
>
> service:bicycle:tyres=yes
>
> a hodgepodge of different ways of tagging and potential for 100s
> of keys.
>
> But it could be so simple:simply structure the value space.
>
> All of the above could be:
>
> sells=tyres:motorcycle;tyres:cars;tyres:bicycle;tools:cars
>
>
>
> or sells=motorcycle:tyres;car:tyres
> or sells=car_tyres;motorcycle_tyres
> or sells=tyres:white:motorcycle...
>
>
> what makes you believe there will be less hodgepodge when we shift
> more information into the values? Look at your own example, there's a
> standardization issue with plural (cars) vs. singular (motorcycle,
> bicycle). Freeform tagging always will bring us also a lot of variants.
>
> If we open the sells="long list" box the only thing that will help us
> maintain a minimum of oversight will probably be the 255 char limit.
> On the other hand I can already imagine people inventing abbreviation
> codes to cram more things into the values.
>
> I am not a CS person, and if the pros agree that overall, value lists
> are better than distinct properties, I will happily accept this, but
> currently I see issues with both. Inconsistent tagging can occur just
> as well in value lists.
>
> Cheers,
> Martin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Facts and opinions

[Simon Poole]

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 thousand uses is not “established tagging practice”.  And I doubt that 
> that usage was ever discussed here or proposed either.  If it was, I missed 
> the proposal where someone said “lets put tyres in a tag already used 3 
> million times for something else”.  My “no” vote on such a thing would not 
> have mattered anyway.
>
> ...

This is not a given, your problem exists just as a consequence of iD
retrieving tag values from taginfo and how iD presets are designed.
Everything else (as in any other editor) definitely doesn't have an
issue with sub-tag keys using the same name as there is more than enough
context to be able to differentiate the different usages. For a new tag
on the other hand we have freedom to as we choose so there is no
specific reason to reuse keys if there is no a good reason to do so.

Generally I think that people are heading of in the completely wrong
direction, while I can understand the desire to be able to document
every single aspect of a shop or other kind of facility, as Stefan has
already pointed out, there are lots of issues with the over name spacing
down to breaking fundamental assumptions about OSM tagging (for example
having capitalized values in keys as in a recent hydrant tagging proposal).

To hypothesize on some of the stuff floating around, obviously there is
a desire to document exactly what kind of stuff a shop sells, so people
have proposed stuff like

motorcycle:tyres=yes

service:tyres:car=yes

service:bicycle:tyres=yes

a hodgepodge of different ways of tagging and potential for 100s of keys.

But it could be so simple:simply structure the value space.

All of the above could be:

sells=tyres:motorcycle;tyres:cars;tyres:bicycle;tools:cars

And please no decade old complaints about lists in tags, we have lots of
structured value tags that work just fine, and yes you could even
document that something is -not- sold in a structured fashion.

Simon




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 all reasonable. The US-Hamlet usage is an oddity that, IMHO, 
>> should not serve as a role model.
> What's odd?
>
> Our administrative boundaries? I can't fix that. (Sometimes, I do
> think US mappers get treated with "the tagging model is fine, fix your
> country!" but I don't *think* that's what you're arguing here.)  We
> also have administrative regions with indefinite boundaries, which
> means that there's some force-fitting in OSM - but that's what we
> have. Not all our county lines have ever been surveyed. (US government
> practice is to map them with a fainter line and the words INDEFINITE
> BOUNDARY as at https://caltopo.com/l/D1KV.)
>
> Our data modelling? In US practice, place=* is based on relative
> importance, not on legal designation. Any boundary=administrative, of
> course, has to follow the legal designation, and in New York at least,
> the designations of 'city', 'town', 'village' and 'hamlet' are based
> on form of government, not on size or importance. That's why we
> *don't* use them to inform place=*, but represent them with
> admin_level=*. (Otherwise, it's a total mess, because of the size
> inversions that I mentioned.
>
> By the way, I'd call it a 'New York State hamlet usage', because other
> states have other forms of municipal government. That's why we have
> that involved table on the Wiki for mapping the administrative regions
> of the different states to admin_level=*.  Also, our admin_level's are
> not strictly hierarchical, because our municipal governments aren't
> either. But we don't have the luxury of making our politics fit our
> map.
>
> Making place=* depend on relative importance or population, while
> boundary=administrative depends on political organization, seems to
> follow accepted OSM practice, as far as I can tell. Where have we gone
> astray?

The weird thing is the mixing of place and administrative entities which
actually leads to the inversion issues, go back read your text and you
will find it difficult to determine when you are talking about one or
the other.

May be we need, instead of using place values, a specific key for
mapping the admin levels to "local" names of administrative entities.

Simon



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



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 complicated and while we have working tagging for
administrative entities (and for them I would normally suggest following
whatever the "official" hierarchy and designation is), our place
modelling is a bit of a mess, which among other issue has led to
administrative boundaries being used for places.

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 all reasonable. The US-Hamlet usage is an oddity
that, IMHO, should not serve as a role model.

Simon


Am 02.01.2019 um 05:12 schrieb Allan Mustard:
> Not according to the wiki.  It seems nodes are the accepted way of
> identifying a settlement, municipal or otherwise.  
>
> On Tue, Jan 1, 2019 at 7:11 PM Martin Koppenhoefer
> mailto:dieterdre...@gmail.com>> wrote:
>
>
>
> sent from a phone
>
> > On 2. Jan 2019, at 00:44, Allan Mustard  > wrote:
> >
> > What do you think?
>
>
> I have never understood why people wanted to add place tags to
> administrative territorial entities like countries, states or
> municipalities. Aren’t these thoroughly defined with
> boundary=administrative and the related admin_level?
>
>
> Cheers, Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 disingenuous, because what is a actually being
>> proposed is
>>
>> characteristic_I_need_to_know:random_string=yes
>>
>>  1000+ more random strings.
>
> usually what you want to know is whether you can top up your mobile phone, 
> not if any kind of top ups are provided, 

Which can be provided by a simple list including the providers name (not
to mention that this allows much simpler fuzzy mapping on the whole set
of supported names, instead of attempting to do the same on keys)..


> so what you call “random string” is actually your mobile phone service 
> provider, i.e. it is part of the characteristic you need to know. Maybe this 
> could lead to 1000 different keys globally, in a country like Italy it is 
> more like 5.
>
> Cheers, Martin 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 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 used is specious, what is
> correct is that the semantics of a key with a list should be documents,
> but once that has been done there is no reason not to do so.
>
> As to the argument with recording non-supported vendors 99.9% of this is
> simply whataboutism, if you can really make a case that you need to
> explicitly record that instead of relying on default semantics, you can
> simply add a key for that.  
>
> Am 26.12.2018 um 16:46 schrieb Martin Koppenhoefer:
>> sent from a phone
>>
>>> On 26. Dec 2018, at 15:08, Stefan Keller  wrote:
>>>
>>> Tag-proposals in the form
>>> :[:]=yes/no should be
>>> avoided. It's shifting values to attribute names!
>> it’s not a value, it‘s a property ;-)
>> it depends on your interpretation, e.g. motorroad=yes 
>> oneway=yes
>>
>> aren’t these values and we should tag them 
>> road_restrictions=motorroad;oneway?
>>
>>
>> top_up:phone=yes
>> means: provides phone top up.
>> For practical reason, I would expect a scheme 
>> characteristic_I_need_to_know=yes/no
>>
>> much easier to evaluate than one like:
>> some_services=foo;characteristic_I_need_to_know;bar
> This is being directly disingenuous, because what is a actually being
> proposed is
>
> characteristic_I_need_to_know:random_string=yes
>
>  1000+ more random strings.
>
>
>>
>> Cheers, Martin 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 used is specious, what is
correct is that the semantics of a key with a list should be documents,
but once that has been done there is no reason not to do so.

As to the argument with recording non-supported vendors 99.9% of this is
simply whataboutism, if you can really make a case that you need to
explicitly record that instead of relying on default semantics, you can
simply add a key for that.  

Am 26.12.2018 um 16:46 schrieb Martin Koppenhoefer:
>
> sent from a phone
>
>> On 26. Dec 2018, at 15:08, Stefan Keller  wrote:
>>
>> Tag-proposals in the form
>> :[:]=yes/no should be
>> avoided. It's shifting values to attribute names!
>
> it’s not a value, it‘s a property ;-)
> it depends on your interpretation, e.g. motorroad=yes 
> oneway=yes
>
> aren’t these values and we should tag them 
> road_restrictions=motorroad;oneway?
>
>
> top_up:phone=yes
> means: provides phone top up.
> For practical reason, I would expect a scheme 
> characteristic_I_need_to_know=yes/no
>
> much easier to evaluate than one like:
> some_services=foo;characteristic_I_need_to_know;bar

This is being directly disingenuous, because what is a actually being
proposed is

characteristic_I_need_to_know:random_string=yes

 1000+ more random strings.


>
>
> Cheers, Martin 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Benefits of namespaces

[Simon Poole]

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 actually have presets values for
specific keys and attempts to retrieve them from taginfo. This in turn
leads to a specific taginfo issue that taginfo can't differentiate
between say: the service key used on a highway=service and the service
key used of railway=service.

With other words: it is really not a preset issue.



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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.

Simon

Am 05.12.2018 um 19:55 schrieb marc marc:
> Le 05. 12. 18 à 19:36, Eugene Podshivalov a écrit :
>> The name tag is abused very often and systematically.  
>> https://www.openstreetmap.org/#map=18/48.86138/2.36028
> just because a hotel's name contains the word hotel does not necessarily 
> mean it is a false name. Some names are "hotêl abc" and not "abc"
>
> the same for the lakes.
> the lake near Geneva (France/Switzerland) is indeed called "Léman"
> and it is a tautology (an error) to say Lake Léman.
> But the "lake of the 4 cantons" in Switzerland is called the "lake of 
> the 4 cantons". If you ask someone where "of the 4 cantons" are located, 
> he don't understand what you're talking about because that not its name.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

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 borders essentially
unusable without making ~200 x "average number of border disputes"
decisions to get to a consistent set of border polygons (which is what
people want in the end).

Simon 

Am 12.11.2018 um 14:32 schrieb marc marc:
> it seems to me that there are 2 possible solutions
> - put the disputed area in the type=boundary boundary+administrative 
> relationship of the 2 countries and put dispute=yes on the way(s) concerned.
> - put the disputed area in neither of the two relationships.
> this area 'll be a mp, and thus a relation type=boundary 
> boundary=disputed make sense.
>
> it should also be ensured that it is a conflict and not simply
> an unintentional inconsistency caused by unshared way
> where they should have been
>
> Le 12. 11. 18 à 14:21, Noémie Lehuby a écrit :
>> Hi,
>>
>> Any thoughts about this ?
>>
>> Should we consider the dispusted=yes tag on boundary ways as a /de 
>> facto/ standard and uniformize a few borders ? Should we create a 
>> proposal about this tag ?
>> The borders data do not fit the doc and the statement from the 
>> Foundation and are not really usable right now...
>>
>> Noémie Lehuby
>> Qwant Research
>>
>> Le 26/10/2018 à 20:52, tagging-requ...@openstreetmap.org a écrit :
>>> Date: Fri, 26 Oct 2018 13:16:20 -0400
>>> From: Yuri Astrakhan
>>> To: "Tag discussion, strategy and related tools"
>>> 
>>> Subject: Re: [Tagging] Add some tag to identify disputed borders ?
>>> Message-ID:
>>> 
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Another related issue -- maritime disputed borders. In the case of Crimea,
>>> the disputed border with Russia is over water, thus not showing clearly in
>>> many renderings, and over land with Ukraine, showing as a solid line - thus
>>> appearing to side with the Russian interpretation.
>>>
>>> A while ago Paul Norman wrote osmborder tool to help with the disputed and
>>> maritime border rendering [1].  His tool mostly uses disputed=yes . The big
>>> problem with rendering was that multiple borders
>>> (city/county/state/country) were all overlapping one on top of the other,
>>> producing a solid line. Instead, when drawing there should always be just
>>> one line with the lowest admin level.
>>>
>>> [1]:https://github.com/pnorman/osmborder
>>>
>>> On Fri, Oct 26, 2018 at 12:05 PM Noémie Lehuby  wrote:
>>>
 Hello,

 There seems to be no actual consensus on the way to map disputed borders.
 The statement from the Foundation
 
 recommend to map the border that "best meets realities on the ground" but
 it's not what is actually in our database:
 See for instance :
 https://www.openstreetmap.org/#map=12/45.8481/18.8378
 https://framapic.org/kIvnPSllBtnv/h1J8xti7US1F.gif
 Both borders (according to Croatia vs according to Serbia) are mapped.

 The same between Soudan and South Soudan:
 https://framapic.org/lcWCkmek7L7i/icYVenvHzPZs.gif

 In some places, there are boundary=disputed or dispute=yes on the boundary
 ways, which is very convenient for a map-maker to know that there is a
 dispute on these border and that you may want to render it with a different
 style (or use another source).
 Should this practice be generalized on all disputed borders or at least
 submitted as a proposal ?

 --
 Noémie Lehuby
 Qwant Research

 ___
 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 mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Opening hours too long for OSM

[Simon Poole]

Am 13.10.2018 um 13:36 schrieb Tobias Zwick:
> Oh, you are right. I am sorry. So that opening hours tool understands
> more than what is defined in the specification.

Everybody that has written a OH parser needs to add a non-strict mode in
one way or the other, or else you wouldn't be 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 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 sensible thing to do, most of the changes proposed are not
>> unambigously parseable and would require us to rely even more on
>> heuristics than we do now to make sense of the values. There a small
>> number of additions that could make sense and make things easier
>> (seasons and some more variable holidays), but they tend to fit in to
>> the existing schema.
>>
>> Simon
>>
>>
>>> Alas, QA tools / the openinghours evaluation tool emit a warning in this
>>> case: "Time range without minutes specified. Not very explicit! Please
>>> use this syntax instead "9:00-17:00"."
>>> Not sure why that is not seen as explicit.
>>>
>>> On 12/10/2018 22:29, bkil wrote:
>>>> That looks like a nice improvement.
>>>>
>>>> Additionally, I've always wondered why we need to enter :00 after
>>>> every hour and zero pad the hours? The shops themselves usually post
>>>> the opening hours as 9-17 - why can't we use this human friendly
>>>> abbreviation? I don't feel that it would be that much harder to parse.
>>>> (9-17h would also work for me) 9-17:30 and 9:30-17 are still
>>>> unambiguous (though, the latter looks a bit uglier at first).
>>>>
>>>> I think this would greatly improve readability, make data entry faster
>>>> and less error prone and shorten the field all at the same time.
>>>>
>>>> Is this fit for a proposal?
>>>>
>>>> On Fri, Oct 12, 2018 at 12:04 AM Robin Schneider  wrote:
>>>>> On 10/11/18 11:47 PM, Jmapb wrote:
>>>>>> On 10/11/2018 5:21 PM, Tobias Zwick wrote:
>>>>>>
>>>>>>> Hey there!
>>>>>>>
>>>>>>> So, a user of StreetComplete came across the following complicated
>>>>>>> opening hours for a shop (prettified):
>>>>>>>
>>>>>>> Jun-Sep: Mo-Sa 10:00-18:00;
>>>>>>> Jun-Sep: Su 10:00-12:00;
>>>>>>> Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00;
>>>>>>> Nov-Mar: Sa 10:00-12:00;
>>>>>>> Apr-May: Mo-Fr 10:00-12:30,15:00-18:00;
>>>>>>> Apr-May: Sa 10:00-12:30;
>>>>>>> Apr-May: Su 10:00-12:00;
>>>>>>> Oct: Mo-Fr 10:00-12:30,15:00-18:00;
>>>>>>> Oct: Sa 10:00-12:30;
>>>>>>> Oct: Su 10:00-12:00
>>>>>>>
>>>>>>> Unfortunately, this does not fit into the opening_hours value, as this
>>>>>>> is limited to 255 characters. What can we do?
>>>>> Hey :)
>>>>>
>>>>> I would say your best bet is to try to shorten the opening_hours values 
>>>>> using
>>>>> every little trick that the syntax has to offer, for example you can join 
>>>>> the
>>>>> month ranges which is enough to bring you under 255 characters.
>>>>>
>>>>> Jun-Sep: Mo-Sa 10:00-18:00;
>>>>> Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00,15:00-17:00;
>>>>> Nov-Mar: Sa 10:00-12:00;
>>>>> Apr-May,Oct: Mo-Fr 10:00-12:30,15:00-18:00;
>>>>> Apr-May,Oct: Sa 10:00-12:30;
>>>>> Apr-May,Jun-Oct: Su 10:00-12:00
>>>>>
>>>>> You can then use the "value to compare to the first value:" feature of
>>>>> https://openingh.ypid.de/evaluation_tool/ to check that you still 
>>>>> preserved the
>>>>> original meaning.
>>>>>
>>>>> I don’t have much to add in case you can not bring the value under 255 
>>>>> only that
>&

Re: [Tagging] Opening hours too long for OSM

[Simon Poole]

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 sensible thing to do, most of the changes proposed are not
unambigously parseable and would require us to rely even more on
heuristics than we do now to make sense of the values. There a small
number of additions that could make sense and make things easier
(seasons and some more variable holidays), but they tend to fit in to
the existing schema.

Simon


> Alas, QA tools / the openinghours evaluation tool emit a warning in this
> case: "Time range without minutes specified. Not very explicit! Please
> use this syntax instead "9:00-17:00"."
> Not sure why that is not seen as explicit.
>
> On 12/10/2018 22:29, bkil wrote:
>> That looks like a nice improvement.
>>
>> Additionally, I've always wondered why we need to enter :00 after
>> every hour and zero pad the hours? The shops themselves usually post
>> the opening hours as 9-17 - why can't we use this human friendly
>> abbreviation? I don't feel that it would be that much harder to parse.
>> (9-17h would also work for me) 9-17:30 and 9:30-17 are still
>> unambiguous (though, the latter looks a bit uglier at first).
>>
>> I think this would greatly improve readability, make data entry faster
>> and less error prone and shorten the field all at the same time.
>>
>> Is this fit for a proposal?
>>
>> On Fri, Oct 12, 2018 at 12:04 AM Robin Schneider  wrote:
>>> On 10/11/18 11:47 PM, Jmapb wrote:
 On 10/11/2018 5:21 PM, Tobias Zwick wrote:

> Hey there!
>
> So, a user of StreetComplete came across the following complicated
> opening hours for a shop (prettified):
>
> Jun-Sep: Mo-Sa 10:00-18:00;
> Jun-Sep: Su 10:00-12:00;
> Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00;
> Nov-Mar: Sa 10:00-12:00;
> Apr-May: Mo-Fr 10:00-12:30,15:00-18:00;
> Apr-May: Sa 10:00-12:30;
> Apr-May: Su 10:00-12:00;
> Oct: Mo-Fr 10:00-12:30,15:00-18:00;
> Oct: Sa 10:00-12:30;
> Oct: Su 10:00-12:00
>
> Unfortunately, this does not fit into the opening_hours value, as this
> is limited to 255 characters. What can we do?
>>> Hey :)
>>>
>>> I would say your best bet is to try to shorten the opening_hours values 
>>> using
>>> every little trick that the syntax has to offer, for example you can join 
>>> the
>>> month ranges which is enough to bring you under 255 characters.
>>>
>>> Jun-Sep: Mo-Sa 10:00-18:00;
>>> Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00,15:00-17:00;
>>> Nov-Mar: Sa 10:00-12:00;
>>> Apr-May,Oct: Mo-Fr 10:00-12:30,15:00-18:00;
>>> Apr-May,Oct: Sa 10:00-12:30;
>>> Apr-May,Jun-Oct: Su 10:00-12:00
>>>
>>> You can then use the "value to compare to the first value:" feature of
>>> https://openingh.ypid.de/evaluation_tool/ to check that you still preserved 
>>> the
>>> original meaning.
>>>
>>> I don’t have much to add in case you can not bring the value under 255 only 
>>> that
>>> I also don’t know any software which would handle that. I guess having the
>>> special cases in an additional tag and `opening_hours` fully valid would be 
>>> best
>>> then.
>>>
>>> opening_hours=Jun-Sep: Mo-Sa 10:00-18:00; Su10:00-12:00; Nov-Mar:
>>> Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00; Sa 10:00-12:00; Apr-May: Mo-Fr
>>> 10:00-12:30,15:00-18:00; Sa 10:00-12:30; Su 10:00-12:00; Oct: Mo-Fr
>>> 10:00-12:30,15:00-18:00; Sa 10:00-12:30;Oct: Su 10:00-12:00
>>>
>>> This won’t work. I had an idea for doing that but this is not supported yet:
>>> https://github.com/opening-hours/opening_hours.js#todo
>>>
>>> --
>>> Live long and prosper
>>> Robin `ypid` Schneider -- https://me.ypid.de/
>>>
>>> ___
>>> 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 mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Opening hours too long for OSM

[Simon Poole]

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 to abstractly discuss such things, it is
another to explain to Josephine mapper that no, the opening hours of the
shop you want to map are one character too long and you need to map less
detail. I just don't believe that "map less detail" is a concept that
you will be able to convey to a majority of contributors and trying to
do is likely futile.  The trend is simply the consequence of progressing
from the rough to the detailed.



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Opening hours too long for OSM

[Simon Poole]

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 mid-clause. In your example,
> I'd probably put all of October in opening_hours_1 so that the
> standard opening_hours tag is correct and parseable on its own.
Just in case somebody jumps on this: using iDs multiple value convention
for this would be a very bad idea (because we are splitting a single
value that needs to be concatenated back together, and you don't want
that to happen with an object that has multiple OH values). Matter of
fact because of iD using the _/n /notation, an extension convention
would likely need to use something else, perhaps #/n/


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Opening hours too long for OSM

[Simon Poole]

PS: an extension syntax has the advantage of not breaking downstream
consumers that are relying on maximum 255 char strings, which is
probably a valid concern. A max length change should probably wait in
any case till there are other data model changes (aka API 0.7 :-)) to
minimize the impact.


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 which should be tackled with a
> general solution.
>
> One would be to extend at least the available space in the database
> for tag values, however that is a significant amount of work (see
> https://github.com/openstreetmap/openstreetmap-website/issues/1593)
> and I suspect it is unlikely to find support.
>
> The other way to address this would be to provide a general value
> extension syntax that editors and consumers could support for example
> say /key-/ext/-nnn  /The exact semantics would need to be determined
> (how to split and join long values) and the key syntax needs to be
> chosen to minimize possible conflicts.
>
> Simon
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Opening hours too long for OSM

[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 which should be tackled with a
general solution.

One would be to extend at least the available space in the database for
tag values, however that is a significant amount of work (see
https://github.com/openstreetmap/openstreetmap-website/issues/1593) and
I suspect it is unlikely to find support.

The other way to address this would be to provide a general value
extension syntax that editors and consumers could support for example
say /key-/ext/-nnn  /The exact semantics would need to be determined
(how to split and join long values) and the key syntax needs to be
chosen to minimize possible conflicts.

Simon




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging