Re: [Tagging] How are protected_area (and national_park) boundaries determined?

[Michael Reichert]

Hi,

Am 24.06.20 um 00:31 schrieb Martin Koppenhoefer:
> in Italy or Germany, the boundaries of protected areas typically either 
> exclude builtup areas or if they are included, there are typically explicit 
> special explanations/provisions for these areas. (there might be exceptions 
> to this, but this is what I have seen).

In Germany, a nature reserve (no matter how large it is) and the rules
applying within its boundaries are declared by a legal norm issued by
the authority for nature protection. Depending on the size, it is either
the county or one more up in hierarchy. Some national parks were
established by a law enacted by the legislative. In all these cases, the
exact boundaries are defined by the legal norm using textual
descriptions and/or maps.

It does not matter who owns the land within the protected area. The
owners need to be heard before the protected area is established and
they can contest the actions of the authority (that's not the case for
protected areas established by the law issued by the parliament). Given
that property needs to serve the public, the interest to protect the
enviroment is usually more important than the right of the owners to use
their property. Mind that the protection usually limit the right to use
only, not totally forbid usage.

However, nature reserves tend to protect areas where a large part of the
land is either owned by the public anyway (municipal and state forests)
because this avoids court proceedings with land owners. But there is no
requirement that the public owns all land in a protected area.

There often signs where paths or roads enter the protected area but the
boundary that matters is written on paper.

Best regards

Michael



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

Re: [Tagging] Feature Proposal - RFC - 3rd and 4th rail

[Michael Reichert]

Hi Colin,

Am 09/06/2020 um 15.36 schrieb Colin Smale:
> Great idea. Not sure about using "3rd" and "4th" though - it's a bit
> tightly coupled to the English language and possibly prone to error.
> Wouldn't "3rail" and "4rail" fit the bill? 
> 
> Actually, as electrified=rail is so widely used at present, how about
> making that explicitly "3rd rail" and introducing a new value for the
> 4-rail system?

I am in favour of splitting "rail" into two new values for systems with
a 3rd and a 4th rail (no matter how it is spelled exactly in the value).
Currently all 3rd rail and 4th rail systems are tagged as "rail", aren't
they? If we followed your suggestion, "rail" would mean "3rd rail or 4th
rail system" and "4th rail" would mean "guaranteed 4th rail system".
It's a bit like "yes" is a incomplete value for electrified=* which
should be replaced by a more precise value like contact_line if one
knows it.

> How would we indicate the voltage/frequency of the two rails
> independently? On the London Underground it's mostly +420/-210 (these
> days +500/-250) but there are some areas where +750/0 is used
> (Richmond-Gunnersbury for example). 

Is voltage=* used on that lines as the difference between positive and
negative, i.e. voltage = 750 = 500 - (-250)?

> While we are at it, could we take the opportunity to find a way to
> represent three-phase dual-overhead systems (Switzerland etc) as well?
For readers being confused: Gornergratbahn in Zermatt uses it.
https://en.wikipedia.org/wiki/Gornergrat_Railway

Best regards

Michael



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

Re: [Tagging] Tagging the presence or absence of signs for surveillance cameras

[Michael Reichert]

Hi,

Am 19.02.20 um 12:45 schrieb Jez Nicholson:
> In general, are these signs physically on the camera, or are they in the
> vicinity? If so, should they be tagged objects in their own account?

In supermarkets and other shops, I do not map surveillance cameras
individually. Instead, I just put surveillance=indoor to the node or way
representing the shop. I do not know if that is a my special tagging
habit nobody else follows but it would be helpful to be able to express
"this place has surveillance cameras and a/no sign".

Best regards

Michael




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

Re: [Tagging] Disputed territory mapped as a country

[Michael Reichert]

Hi Alexey,

Am 27/01/2020 um 17.07 schrieb Захаренков Алексей:
> Today I discovered a new country in OSM, created in 
> https://www.openstreetmap.org/changeset/80105029
> with the name "Disputed territory between France and Italy" and tags 
> "type=boundary + boundary=administrative + admin_level=2+ disputed_area=yes". 
> The relation itself: https://www.openstreetmap.org/relation/10629103
> Me and the changeset author could not come to agreement if the territory is 
> mapped correctly. Please put an end to our dispute.

Thank you for the heads-up (although the Talk list might be an
appropriate place as well).

boundary=administrative + admin_level=2 is reserved for independent
countries which sovereignty their territory. (The definition of
independence and sovereignty are a bit complicated and I do not go into
details for the sake of brevity here).

One might argue about the level of independence and sovereignty of some
countries but this are up in the mountains is just an overlap of claims
and not an own country itself.

I removed this wrong tagging and commented on Very_p's changeset.

Best regards

Michael



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

[Michael Reichert]

Hi Tobias,

Am 28.10.19 um 19:45 schrieb Tobias Zwick:
> Most commonly, a cycleway that just ends without merging it back onto the 
> street.

Do you have images illustrating this?

Best regards

Michael



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

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

[Michael Reichert]

Hi Nick,

Am 23.05.19 um 21:58 schrieb Nick Bolten:
> # 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 an import, but this didn't stop there being several insulting
> accusations from several long-term OSMers on these lists. Those students
> were motivated by helping other people and spent literal months attempting
> to gather enough information from underspecified tagging standards and
> would have been put off the community entirely if it weren't for the
> project's momentum and much more productive and friendly interactions with
> local OSMers. I think it's probably a good thing that it's so hard to even
> know that there is a mailing list, as users have a negative experience.

Your criticism might have some true points and I am happy that is a bit
more elaborated than a simple "mailing lists are bad and a toxic space".
Don't you think that an accusation without a proof (link to mailing list
archive where I can re-read the discussion that happened at that time)
makes your claims more substantial?

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

[Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Michael Reichert]

Hi,

I discovered today that iD suggests to add highway=footway to
railway/public_transport=platform objects as part of its new validation
rules. On a GitHub ticket I found, Quincy Morgan explained it that way [1]:
> Features with these tags are expected to be part of the pedestrian network, 
> but without highway tags it is more difficult for routers (and iD's 
> validation) to support them. iD should add highway=footway automatically and 
> recommend upgrading features lacking this tag.

I disagree with that.

(1) Calling it difficult for routers is a weak reason. Currently, a
router can decided to include platforms in the graph or to exclude them.
Some do support or intentionally not support platforms. Platforms are
something special. There are subtle but relevant differences to normal
footways, e.g. the requirement to have a ticket (even without barriers
present) or a cycling ban [2]). These differences are hidden by adding
highway=footway.

Instead of making life easier, life stays as difficult for the developer
of routing engines but they have to change their code just for the sake
of changing. If iD starts adding highway=* to any platform, all routers
supporting the current tagging schema have to change their behaviour.

(2) The following numbers (data from 2019-05-21T22:58:37Z) show that the
change should be treated as the redefinition of a existing tag.
highway=footway is rarely used on platforms now – currently 0.4% only.

(Typewriter font recommened for optimal display of the following tables)

pt: public_transport=platform
r: railway=platform
f: highway=footway
pe: highway=pedestrian
ways_linear: non-closed ways and ways without area=yes
ways_area: closed ways with area=yes

Planet:
typeptrptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes  1099931   203   8578   0  0 00   0
ways_linear 127899 24505 32096 3964 306970528   8
ways_area31652 19560 35729  265  15342   171   15  14
relations  818   614  31832   0 23120   1

US:
typeptr   ptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes70394   19   2420   0  0 00   0
ways_linear   1196 1023  1940  148  12361 20   0
ways_area  674 1303  2233   10   0 32 60   1
relations   10   11140   0  0 10   0

Germany:
typeptr  pt+r pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes   178981   15   1011   0  0 00   0
ways_linear  36427 1012  7143  663  41172 20   0
ways_area 7891  481  9823  184   1269485   9
relations  274   35  19681   0 16 40   1

France:
typeptr  pt+r pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes   1028218360   0  0 00   0
ways_linear  17179 1342  2609   46   3 29 00   0
ways_area 1173 1190  19415   1  2214   0
relations   12  104530   0  0 10   0

Great Britain:
typeptr   ptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes370789 20   0  0 00   0
ways_linear300 2412  1012   18   7 15 10   0
ways_area   59 2076  12430   2  0 30   2
relations3   31850   0  0 00   0

Poland:
typeptr   ptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes22073   11 90   0  0 00   0
ways_linear   9294  996   783  615   7 25 20   0
ways_area10327 2612  2189   42   0 24 62   1
relations   37   14370   0  0 00   0

Switzerland:
typeptr   ptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes 67273 00   0  0 00   0
ways_linear   5945  112   805  151   4  4 00   0
ways_area  376  114  18641   0  3 00   0
relations   119   2480   0  0 00   0

Italy:
typeptr   ptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes317375120   0  0 00   0
ways_linear   3902 1435   757   43   8  0 10   0
ways_area  190 1028   7141   0  0 30   0
relations9   21 70   0  0 00   0

Japan:
typeptr   ptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes371857130   0  0 00   0
ways_linear910  785  11109   1  1 00   0
ways_area  342 1295  22070   0  0 20   0
relations   24   38850   0  0 00   0

It is quite obvious that highway=footway on platforms is exotic.

(3) highway=footway is added to ways which are clearly tagged as area
using area=yes. Many routers route along the edges of areas but that's
more a bug and workaround than a good feature. A 

Re: [Tagging] what todo if the status of a propal isn't set to Voting ?

[Michael Reichert]

Hi,

Am 08.05.19 um 22:14 schrieb marc marc:
> Some use the status to check propal with the status=Voting
> https://wiki.openstreetmap.org/wiki/Category:Proposals_with_%22Voting%22_status
> but some propal fail to have it, currently
> https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch
> 
> what todo in this case ? only fix the status or also extend the voting 
> period to allow ppl to have enought time to see it ?

The voting is invalid and has to be repeated.
https://wiki.openstreetmap.org/wiki/Proposal_process#Voting is quite
clear (emphasis as given on the wiki page in bold font)
> Set the *status=Voting, voteStartDate=* and *voteEndDate= +14>* (-MM-DD).

I added an ambox (type=info) to the voting section of the proposal.

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] 'track_detail' on railway lines - what does it represent?

[Michael Reichert]

Hi Dave,

Am 21.04.19 um 13:37 schrieb Dave F via Tagging:
> 'track_detail, used on railway tracks.
> 
> https://www.openstreetmap.org/way/4414158
> 
> 4700+ total worldwide  3900+ in the UK
> 
> I can find nothing in the wiki
> 
> Is track_detail meant to indicate that all tracks have been mapped?
> Surely that can be noted just by looking at the map?

I don't know the meaning but I can point to a similar track
detail=track. It is used in Germany by a few mappers in a few regions
(mainly south-west) and if each track is mapped with an individual way.

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Stop the large feature madness (was: Tag for a plateau or tableland?)

[Michael Reichert]

Hi,

Am 18/04/2019 um 18.52 schrieb Christoph Hormann:
> On Thursday 18 April 2019, Kevin Kenny wrote:
>> Please avoid the term "label painting." What you call "label
>> painting" is the entirely reasonable desire to have recognized, named
>> objects appear on the map with their names.
> 
> I distinguish between names and labels.  Labels are graphical 
> representations of names or other strings in map renderings.  The OSM 
> database should not contain labels, it should contain names.
> 
> This:
> 
> https://www.openstreetmap.org/relation/9359806
> 
> is not a named representation of a verifiable element of the geography, 
> it is a labeling geometry.  Creating such is not mapping, it is label 
> drawing or label painting.  It is neither meant nor suited to do 
> anything other than performing a relatively simple label placement.
> 
> Note by speaking of "label painting" i do not intend to assign one sided 
> blame to mappers for doing so.  In most cases this is as much the fault 
> of map designers encouraging this as it is of mappers to respond to 
> this incentive.

+1

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Feature Proposal -- RFC -- service=irregular

[Michael Reichert]

Hi Markus,

Am 01.04.19 um 11:52 schrieb Markus:> I'm proposing the tag
service=irregular for tram, light rail,
> underground and other railway tracks not used for regular scheduled
> passenger services, but only for diversions or shortcuts.
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:service%3Dirregular
> 
> Any feedback (on the wiki talk page or on the tagging mailing list) is
> much appreciated!

The service=* tag on railway=* has been used for the function of a track
as a part of the infrastructure up to now. Your proposal extends its
meaning to the services on the track. This tag is in conflict with
service=siding because there are quite a lot tracks in stations which
are not used by passenger trains according to the timetable.

The presence of service=* on a track is used by data consumers as "this
tag is not the main track through the station, skip it at lower zoom
levels". Following your logic, service=irregular has to be used for a
lot of branch and all freight-only or almost freight-only lines breaking
with existing usage of service=*.

Limiting service=irregular to railway=light_rail/tram/subway will not
help. There is no well-defined border between heavy rail on the one side
and light rail on the other and between light rail and tram and between
light rail and subway. There are a couple of tram-train systems where
railway=light_rail sections are operated as a normal railway with
stations and service=siding tracks.

Currently, service=* serves quite good the view of railway
infrastructure operators on their tracks.

Don't you think that your view on the infrastructure is too narrow?
There aren't passenger trains only. OSM data is used by freight train
operators as well. A track used irregularly by passenger trains might be
use frequently by freight trains.

That's why I think that this is no example for good tag design.

In general, the services on the infrastructure should be mapped as route
relations. Tracks without route relations or with route relations tagged
as "only a few times a day or during peak time only" should get special
tag to mark their "irrelevance". If you know which tracks are served
irregularly in a tram network, you should have gained the knowledge
about the routes already and should be able to map them. Therefore, I
would like to see a proposal to tag highlight the main variant of a
tram/train/light rail/subway line without going to much into the details
of departure times.

Do you know railway:traffic_mode=passenger/freight/mixed? Your tag might
follow that approach if you think that route relations cannot serve the
needs.

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)





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

Re: [Tagging] Feature proposal - RFC - Line attachments

[Michael Reichert]

Hi François,

Am 08/03/2019 um 00.35 schrieb François Lacombe:
> The line attachments proposal has been updated according to comments
> received all along past weeks. Thanks to TOGA and Nakaner mainly.
> https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_clamps
> 
> It is not restricted to power nor telecom lines. Any line can be anchored
> or held with suspension clamps over heads.
> 
> This sounds to be ok for me and may be voted shortly.
> Feel free to raise objections or comments prior of this to help building a
> more useful tagging.

You propose to use semicolons to separate the values if the cables at a
mast have a different suspension:

line_attachment=suspension_clamp;pin;suspension_clamp

We have a similar issue when tagging different speed limits on road
lanes and use a | to separate lanes (minspeed:lanes=90|90|40).

Unfortunately, the cables of a power line can be located on multiple
levels. Therefore, you propose to use semicolons to separate cables at
the same level and vertical bars to separate levels. A semicolon has a
slightly different meaning in OSM.

I would like to see line_attachment=* only for masts where all cables
are mounted equally and propose to use line_attachment:cables=* if one
value does not fit all cables.

In order to circumvent the semicolon issue, I propose to introduce round
braces for all cables of one level.

https://wiki.openstreetmap.org/wiki/File:Pole_multi_attachement.png
would be tagged like this:
line_attachment:cables=(suspension_clamp|pin|suspension_clamp)|(suspension_clamp)
This avoids using adding variable parts into keys (line_attachment:1=*,
…) which I myself could not call "good tag design".

Best regards

Michael aka Nakaner


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Public Transport Timetables Proposal RFC

[Michael Reichert]

Hi Leif,

Am 16/02/2019 um 15.04 schrieb Leif Rasmussen:
> Here is a link to the current proposal, which everyone with a wiki account
> can now vote on:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_schedules/Departures

Please mind the rules documented at
https://wiki.openstreetmap.org/wiki/Proposal_process#Voting You
currently lack

- a proper notification email (please start a new thread on the mailing
  list, don't click on "Respond" in your email client)
- a start and end date for the voting on the proposal page

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Public Transport Timetables Proposal RFC

[Michael Reichert]

TL;DR I am agains this proposal. Timetables in OSM are an ugly hack.
Please store them outside of OSM and link them using foreign keys.


Hi Leif,

Am 31.10.18 um 00:54 schrieb Leif Rasmussen:
> I recently wrote up a proposal page for public transport schedule data.
> This information would allow OpenStreetMap to store information about when
> or how often certain buses or trains arrive at a platform.
> 
> https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules

I think that the frequency and the days a route is served is sufficient.
There should not be any more details about the timetable in OSM beyond
that. While public transport looks simple :-) if you look at urban
areas, it becomes difficult to model if you go to the boundary of urban
areas or even into rural areas or developing countries.

OSM already struggles to model route relations for bus lines which have
15 trips per day but 12 different variants (e.g. bus lines in rural
Germany). How do you deal with train lines which run on days matching
the following specification only?

> nur Fr, So
> auch 22.XII., 26.XII., 27.XII., 1.I., 2.I., 28.II., 6.III., 14.II.,
> 18.IV., 22.IV., 30.IV., 1.V., 2.V., 29.V., 30.V., 11.VI., 2.X., 30.X.
> nicht 21.IV., 31.V., 1.VI., 9.VI., 21.VI., 4.X.
>
> Fr = Friday
> So = Sunday
> nur … = on … only
> auch … = also on …
> nicht … = not on …

This specification changes every year and it can't be simplified to "Fr,
Su and public holidays in at least two German states". Currently, many
route relations don't have to be modified every year but your tagging
schema would force mappers to do so. And the example above is quite
simple. In practice, the specification is even longer because many
constructions to refurbish the railway network a running and lead to
different departures nearly every second weekend or trains don't serve
the whole line from start to end because parts of the line are closed on
some weekends/weeks during the year due to constructions.

How would you deal with lines which have a clear interval of 60 minutes
if you round all depatures and arrival times? There are a lot of train
lines where the times differ by a +-3 minutes through the day. Peak vs.
off-peak is not the reason.

OSM was designed to be a database for geometries with attributes. The
database design of OSM has some issues but I am sure that database
designed for public transport timetables would not require the timetable
to be encoded into relation membership roles and relation tags.

Using OSM to encode timetables looks more like a ugly hack and should be
solved by having some kind of foreign key as tag of the route relation
which is used by a separate database project under a free and open
license which is designed for and used to store timetable information.

Nobody forbids anyone to run a project for crowdsourced timetable
information. But it is out of scope for OSM.

Your tagging proposal suggests to use relation membership roles to store
depatures in a way like that:
"platform:Mo-Fr 08:40, 09:40, 10:40, 11:40, 12:40, 13:40, 14:40, 15:40,
16:40, 17:10, 17:40, 18:10, 18:40, 19:40, 20:40"

Aren't membership roles limited to 256 characters, too?

In addition, your tagging schema is incompatible with the current public
transport tagging schema and probably all recently discussed proposals
which aim to replace or improve it. All of them know a role "platform".
From my point of view, relation membership roles are keys. Keys should
not contain value information.

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)




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

Re: [Tagging] Topographic Prominence for Peaks

[Michael Reichert]

Hi Joseph,

Am 23.09.18 um 02:00 schrieb Joseph Eisenberg:
> Elevation and prominence can both be calculated from SRTM data, eg by
> using Opentopomap tiles and finding the highest contour lines around a
> peak, and the lowest near a saddle.
> 
> Prominence and elevation can be calculated by computer with good data,
> but for my part of the world the SRTM data is not high enough quality
> to get good results without cross-checking against aerial imagery.
> Also the calculations are not simple, and are not precise for sharply
> pointed peaks or deeply carved saddles, therefore I believe it will be
> useful to include this data directly in tags.
>
> I also find that calculation the prominence of peaks has encouraged me
> to add more ridge lines and saddle points (with elevations), which
> should make the database more useful in mountainous areas.
> 
> Do you think I should write up a formal proposal for this tag?

I don't think that there is any need for such a tag in OSM for the
following reasons:

(1) If you assume the earth to be a plane, just order the peaks by their
elevation. It's so simple that I don't give the necessary SQL query
here. If we used a prominence=* key, it would have to be the distance to
the next higher peak. If the value were not a number but a term like
"most_important", "very_important", "neighbour_of_highest" etc. it would
not comply with the verifiability requirement of OSM and invite people
to have edit wars.

(2) If you assume the earth to be an ellipsoid, it is more difficult but
still achievable with ele=* tags in OSM and elevation raster data (SRTM
etc.) only. There is an open source solution to do so.
https://gitlab.com/nuntius35/extremal_peaks/blob/master/README.md
(mentioned in WeeklyOSM issue 423)

(3) If we use a tag like prominence=* for peaks two mappers will have a
different opinion on the value to choose. For example, the Matterhorn is
4478 m high but Monte Rosa is 4634 m high and not that far away.
However, the Matterhorn is more famous and people expect it to appear on
maps at the same or lower zoom scales than Monte Rosa. Whose opinion is
correct? From my point of view, the mapper using the elevation only
because that is the only verifiable fact while the prominence in
advertisement is something we don't record in OSM for a very good
reason. (Please replace "peak" by "city" and "height" by "population"
and read this paragraph again)

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] micromapping complex level_crossing

[Michael Reichert]

Hi Martin,

Am 29.08.18 um 11:55 schrieb Martin Koppenhoefer:
>> On 29. Aug 2018, at 10:47, joost schouppe  wrote:
>>
>> Has anyone of you seen a good example of a micromapped complex level 
>> crossing?
>>
>> Given how much we like trains, I'm surprised I didn't find a solution 
>> straight away, so I'm probably missing something.
> 
> 
> 
> you could use
> railway=sleeper
> for individual sleepers. Or which detail are you interested in?
> ;-)

It seems that they are interested in barriers and lights micromapping.
(You could call it signal mapping but for cars)

Jakka asked a more precise question on the OpenRailwayMap mailing list
today.
https://lists.openrailwaymap.org/archives/openrailwaymap/2018-August/000589.html

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Part/whole confusion with Wikidata tag, and the need for enveloping parts into a whole

[Michael Reichert]

Hi peterkrauss,

Am 08.08.2018 um 03:18 schrieb Nelson A. de Oliveira:
> On Tue, Aug 7, 2018 at 9:22 PM, Yuri Astrakhan  
> wrote:
>> Nelson, there are several places I have seen in our wiki, e.g. [1], which
>> discourage duplication of information if it can be avoided. name is a
>> special case - it helps mappers to quickly identify what the object
>> represents. If we duplicated everything, than each part of a railroad
>> station should have duplicate web site URL, hours of operation, operator
>> name, and tons of other info. Having duplicates lead to inconsistencies,
>> harder to maintain, etc.  For example, if two parts of the station have
>> different hours of operation - is that a mistake (someone forgot to update
>> both), or is it intentional? Which one of two is correct? Having a rule to
>> keep common info in a relation unless it is different makes data more
>> valuable and less error-prone.
> 
> I was talking about any object.
> And I fail to see what exactly is *wrong* in having multiple parts of
> an object with the same wikidata; it's not really duplication.
> 
> We don't create relations to avoid repeating surface, lanes, name, etc
> on every part of a highway, for example.
> Using relations also has the drawback of creating complexity for most
> of the users in OSM (and sometimes even for the data consumers),
> specially if the main objective here is to solely avoid non-unique
> wikidata values.

I second that.

Our data model is different from the data model of Wikidata.

It is common practice when mapping railway lines to add tags which refer
to a railway line (as a infrastructure, not the services using it) to
the ways.

Example: Tags of a way

railway=rail
name=Linke Rheinstrecke (English: Left Rhine Railway)
wikipedia=de:Linke Rheinstrecke
wikidata=Q…
operator=DB Netz AG

This duplication is common practice in OSM even if it does look wrong to
proponents of the pure doctrine how to design a database. OSM is not
modified by a frontend application hiding the database model from the
user. Instead, it is edited by humans how have to understand the
database model. Many of them already struggle with understanding
relations at all.

That's why we do not create a relation to collect all objects having the
same operator. Instead, we add operator= to all the objects. Such
relations are called "collective relations" and not welcome.

https://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories

Route relations for railway lines (infrastructure, not the services) are
some of the exceptions from that rule.

OSM is a project with a lot of data. If we represented all much more of
the information which is currently "duplicated" as tags on individual
objects, processing of OSM data would become more difficult, expensive
and slower due to the many JOINs (I assume you are more familiar with
database terminology).

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Unresolved notes

[Michael Reichert]

Hi Graeme,

Am 17.06.2018 um 08:24 schrieb Graeme Fitzpatrick:
> Sorry, copied mixed info
> 
> This bit should show
> 
> Others are showing as a note apparently at a location
> https://www.openstreetmap.org/note/1037676 but then it appears there's
> nothing there to fix https://www.openstreetmap.
> org/edit#map=17/-27.96197/153.40334

The note looks like SEO spam but dumped into notes than into map objects
(nodes and ways). You might try what geocoders of Google and other
companies return as result for that address. Maybe it is exactly that
location?

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] `amenity=shelter` implies `building=yes`?

[Michael Reichert]

Hi Bryan,

Am 17.06.2018 um 06:45 schrieb Bryan Housel:
> Does `amenity=shelter` imply `building=yes`?
> 
> The osm wiki page does not suggest `building=*` as a “tag to use in 
> combination”
> https://wiki.openstreetmap.org/wiki/Tag:amenity=shelter 
> 
> 
> But most other features which are closed-way structures need the `building=*` 
> tag.  I know it’s a tag used by 3D mapping.  It seems like for consistency, 
> we should add an explicit `building=*` tag.
> 
> Asking for https://github.com/openstreetmap/iD/issues/5084 
> 

Please keep in mind that there are not only shelters in the countryside
and the mountains but also at thousands of bus stops. While shelters for
hiking usually look like small buildings, shelters at bus stops don't.

The following three are no buildings from my point of view because they
have one wall only. Either the two other walls do not fully stretch from
the ground to the roof or the shelter itself can be removed easily.

https://www.mapillary.com/app/?lat=49.08680549357706=9.078079866007897=17=90pd5WuYg8zOk_L8dxLFFQ=photo

https://www.mapillary.com/app/?lat=49.08985722389377=9.07931005221235=17=oXQHKqb3Lc3Ae9IXj-5PHw=photo

https://www.mapillary.com/app/?lat=49.10616167487336=9.121348618135698=17=8xUGL_VKp45sOfd9VW7dUw=photo

There is building=roof but I would not use it for such shelters. They
are not treated as buildings by the cadastre, why should I do? (If they
are larger and have no walls, they

I think that nobody of us knows the whole world and that's why I ask you
not to decide on the default values of the whole world. If local mappers
think that a shelter is a building, they will tag it as such. If they
think that it does not qualify to be a building, they will not add the tag.

Adding missing default tags is easier for data consumers than removing
potentially wrong and superfluous default tags.

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

[Tagging] When was the deprecation of location=kiosk for power=substation discussed?

[Michael Reichert]

Hi,

while adding a substation to OSM yesterday I looked up the possible
values of location=* and missed kiosk. A short glance in the history
showes that it removed location=kiosk from the page on 2018-01-02. The
edit description mentions man_made=street_cabinet+street_cabinet=power
as a replacement.

https://wiki.openstreetmap.org/w/index.php?title=Tag:power%3Dsubstation=1542685

location=kiosk was introduced by the approved Substation Refinement
Proposal in 2013.
https://wiki.openstreetmap.org/wiki/Proposed_features/Substation_refinement#Substation

man_made=street_cabinet was introduced by the Street Cabinet Proposal in
2014.
https://wiki.openstreetmap.org/wiki/Proposed_features/Street_cabinet
This proposal does not mention substations or transformers at all.

I think that small substations are not street cabinets because they are
much larger than street cabinets and are usually not located on the
sidewalk but next to it on a separate area.

I don't remember a discussion of this change, do you? If no, I propose
to revert this change on the wiki.

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Feature Proposal - Voting - hail and ride

[Michael Reichert]

Hi Michael,

Am 10.04.2018 um 17:45 schrieb Michael Tsang:
> The proposed feature "hail and ride" is open for voting:

Could you please provide a link to the wiki page?

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Michael Reichert]

Hi,

Am 31.03.2018 um 17:00 schrieb Johnparis:
> This implies the following changes to v2:
> 
> 1) every platform node should have mandatory {mode}=yes tag(s)

I also think that public_transport=platform without *=yes tags is some
kind of incomplete.

> 2) stop_positions should be optional on the map and should not be included
> in the route relations

Stop positions should be optional but there are some cases where they
are useful. If they are mapped, they should be added to the route
relation. If we don't add them to the route relations, we can skip them
at all.

> I'm inclined to agree with the wiki that the v1 tags on nodes should remain
> (including the two million highway=bus_stop tags).
> 
> I don't really see a big advantage in changing the value of the v2 tag from
> public_transport=platform to something like public_transport=wait_area (and
> there are about one million public_transport=platform tags at the moment).

+1

If you try to invent new tags just to replace old tags and the old tags
are used very often, a proposal is doomed to fail.

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Unclear meaning of amenity=bus_station

[Michael Reichert]

Hallo Mateusz,

Am 09.04.2018 um 12:55 schrieb Mateusz Konieczny:
> Currently definition at
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dbus_station
> is unclear, it fits two cases
> 
> * intercity bus station (routes between cities, importance comparable
>   to railway=station)
> * terminus highway=bus_stop (routes within city terminate and start
>   here, minor importance, importance lower than railway=halt)

In Germany, mappers also use amenity=bus_station for interchange hubs of
local buses where multiple buses stop at the bus station at the same
time. Towns usually have one or two large bus stations (often next to
the train station), called "Zentraler Omnibusbahnhof" (ZOB) or
"Busbahnhof" (central bus station; Bahnhof = station).

> Would it be OK to edit wiki and restrict it only to the first meaning?

I think that the the second meaning could be removed.


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Michael Reichert]

Hi Christian,

Am 28.03.2018 um 16:21 schrieb "Christian Müller":
> In your proposal you complain about subjectively felt things like "history 
> won't go away", but at the same time you are trying to revert a part of 
> history itself - "the public_transport tags are seven years old now".  Many 
> people were involved creating those tags, they are well understood and 
> discriminate the features they describe in a thoroughly documented and 
> plausible way.
> 
> Just because a lot of deprecated tags have not vanished in favor of the new 
> ones yet does not mean there is a preference on the deprecated tags.  A lot 
> of users and apps have adopted the new public_transport tags.  It simply does 
> not make any sense to do a rollback on these for the observation of a 
> sluggish adoption/transition rate.
> 
> The proposal has been long thought about and delivers, in itself, a coherent 
> way of tagging public transport infrastructure.  It has learned from previous 
> tags, it is thus a refinement of the previous tagging.  There will be lots of 
> people -unheared and not- that oppose breaking a (slow moving) transition 
> process at this point in time.  Just be patient and give it some more years.

I am in favour of PTv2 but have to admit that PTv2 is a great example
how proposals can fail. I joined OSM a few months after PTv2 was adopted
and started using it in 2014. The reasons for its failure are:

- PTv2 has a long and detailed proposal page but after the proposal was
accepted, it was only documented on the proposal page for a long time
while many other pages (some might still do) explained the old schema.

- If someone propose a tagging schema which is not just a new tag or a
few new tags but includes a new type of relation (stop areas, routes
which contain stops etc.), he should provide a application which
demonstrates the usage and/or serves as validator. That did not happen.
Adding support for that type of relation to at least one widely used
data consumer tool like Osm2pgsql will make more users use the data
(currently you have to rely on the slim tables of Osm2pgsql which is a
hack because they are not considered to be stable).

- If someone writes such a complicated proposal, he should ask the
authors of map styles (if he isn't someone himself) for their opinion on
the new tags. public_transport=stop_position/platform isn't easy to
render without taking highway=bus_stop into account because (1)
platforms do not have to be tagged with bus/tram/train/subway=yes and
because you do not have to map both the platform and the stop. If you
render only stop positions or only platforms, you will miss features in
some areas. If you render both, you will have duplicated map icons.
Checking if there are nearby features, does not work as good as manual
selection (I wrote my own SQL queries to group stops and platforms to
form stations in the past – it doesn't work very good).

- The proposal was not understood by significant parts of the community.
Many mappers think that highway=bus_stop and
railway=station/halt/tram_stop are deprecated and use them because some
important applications do not use public_transport=*. (see the quoted
posting above) However, they aren't.

All in all, I would like to thank Ilya for investing time into this
topic even if I do not agree with him on all questions and do not like
some parts of his approach (change tagging in foreign cities using
non-local staff which does not declare its affiliation).

Best regards

Michael


PS This email was written before I read the new proposal by Ilya.


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Tagging fraction house numbers?

[Michael Reichert]

Hi,

Am 2018-03-13 um 12:22 schrieb James:
> in case it wasnt bad enough, there's 40A to the right of it:
> 
> https://i.imgur.com/MhED15C_d.jpg?maxwidth=640=thumb=medium
> 
> if we are using ASCII do we put a space between 40 and 1/2 to avoid 401/2?
> it's the main advantage of using ½ so you can easily decifer what it
> is(apart from multi-byte character parsing)

Bavaria has a lot of them. Mappers in Bavaria use spaces.
https://overpass-turbo.eu/s/wYq

To make things even more weird, they also have housenumbers like 129
1/2a, 129 1/2b, … (where the city needed numbers between 129 1/2 and 131
and did not use 129 5/8, 129 3/4, 129 7/8).
https://overpass-turbo.eu/s/wYn

Best regards

Michael


[1] I wrote "Augsburg" because a mapper from Augsburg telled me about
that numers a few years ago. However, these numbers are used in all
districts of Bavaria.


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Tagging fraction house numbers?

[Michael Reichert]

Hi James,

Am 2018-03-12 um 16:43 schrieb James:
> https://i.imgur.com/eigT5hX_d.jpg?maxwidth=640=thumb=medium
> 
> How should this be tagged in housenumber? Using unicode ( ½ ) or ASCII( 1/2
> )?

Augsburg (Germany) has such house numbers. They use ASCII representation.

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Subway vs light rail

[Michael Reichert]

Hi Fernando,

Am 2018-01-04 um 13:32 schrieb Fernando Trebien:
> A German mapper just changed the rail type of a line [1] in my area
> (southern Brazil) from light_rail to subway.
> 
> Here those trains run on the surface (contrary to most subways) and
> have no at-grade intersections with other traffic (contrary to most
> light rail systems). Also, metro systems like this are usually
> considered "heavy rail," [2] so it really doesn't look like this
> should be "light rail". It is also not simply railway=rail since it is
> not the highest level of rail service and it only carries passengers.
>
> […]
>
> [1] http://www.openstreetmap.org/relation/420335

The relation you refer to is now a public transport version 2 relation.
light_rail is no valid value for route=* in this schema. It is only a
valid value for railway=* (the infrastructure).

Subways don't have to run underground. There are lots of subway systems
with long sections outside tunnels, either elevated on bridges or just
on ground level because it is cheaper to build and maintain and space
was available. The key feature of railway=subway is the separation from
other traffic and the absence of at-grade intersections.

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Feature Proposal - Voting - (Fire Hydrant Extensions)

[Michael Reichert]

Hi Alberto,

Am 16.10.2017 um 19:28 schrieb Viking:
> Voting ended with 21 "no" and 28 "yes", and at least one that would change 
> "no" to "yes" if we redefine gallons.
> Now we have to do decide what to do. Is this enough to delcare it approved?

A quote from the wiki (page Proposal_process#Approved):
> A rule of thumb for "enough support" is 8 unanimous approval votes or at 
> least 10 votes with more than 74 % approval, but other factors may also be 
> considered (such as whether a feature is already in use). All suggestions 
> should be taken into account before a proposal is approved or rejected.

I think that this is very clear.

I myself was surprised a few days ago that a proposal needs a 3/4
majority, too.

> Anyway some issues can be easily solved:
> 
> fire_hydrant:class=* can become fire_hydrant:awwa_class=*
> gpm can become usgal/min
> fire_hydrant=* can remain fire_hydrant:type=*
> 
> Instead for:
> 
> diameter=*
> pressure=*
> location=*
> 
> We must first of all decide if go on or not.
> In the affirmative case, we must document very well the reasons why we want 
> to use them, and we must expect a transition period in which existing tags 
> remain and new tags are used alongside them.
> 
> For all other  points that haven't been contested, I consider them approved 
> and I would start to add them to fire_hydrant page.

I think that either a whole proposal is approved or not. You cannot
declare parts of the proposal as approved because the voting was on the
whole, not on each part independently. How would you count the votes
against the proposal if the voter did not write a comment (comments are
not required).

> We can't block this proposal any more. In a way or in another we need the new 
> tags as soon as possible.

I myself am not against the proposal and agree with parts of the
proposal but you should still write multiple new ones. Split your
proposal into two or more parts which can exist independent from the
other parts. It is a burden but just adding tags from a large, failed
proposal to feature pages has some similarities with the
motorcycle_friendly case we discussed on this mailing list a few days ago.

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Feature Proposal - RFC - Validity of Route Relations

[Michael Reichert]

Hi,

Am 2017-10-14 um 06:49 schrieb Jo:
> Maybe
> 
> recheck_itinerary_route_by
> 
> would be a better tag. Then it can also be used when route relations are
> changed for roadworks that take more than say, a month and that cause
> changes in itinerary.

If recheck_itinerary_route_by= reduces the confusion (see email by
Andrew) and nobody opposes on this mailing list (or a parallel
discussion), I will change the proposed tag. In addition, this tag will
hopefully discourage mappers from adding a start_date equivalent
although it was not proposed (An end implies a start, doesn't it?).

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Feature Proposal - RFC - Validity of Route Relations

[Michael Reichert]

Hi,

Am 2017-10-14 um 00:29 schrieb Jo:
> 2017-10-13 23:59 GMT+02:00 Andrew Davidson :
> We don't have a scheme to tag the timetables and it would be quite hard to
> come up with one, involving many relations we don't want to maintain.
> Better to leave that part to GTFS.
> 
> So the proposal is about the routes/itineraries that change, stops that
> aren't served anymore or new stops added to the lines. Not about the bus
> passing by 10 minutes earlier at 8 am on Wednesdays.
> 
> That's the way I understand it, anyway.

That's my intention.

I think that timetable details (departure times) should not be mapped in
OSM due to the reasons given by Jo.

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Feature Proposal - RFC - Validity of Route Relations

[Michael Reichert]

Hi Warin,

Am 2017-10-13 um 23:22 schrieb Warin:
> On 14-Oct-17 04:11 AM, Michael Reichert wrote:
>> end_date=* is used on disused objects or objects whose last day of
>> operation/service is known. Common examples are disused railway tracks
>> or shops which announced the last day they will be open. The latter
>> example is mainly used in areas with a high density of active mappers.
>> :-)
>>
>> The wiki page you linked to discourages the use of end_date=* because
>> historic information is kept in OSM only until a certain limit. An
>> object with highway=trunk + end_date=2016-05-21 should be tagged
>> highway=disused + disused=trunk (or lifecycle prefix instead) and maybe
>> with end_date=* because data consumers are not used to look on secondary
>> tags which invert the meaning of the main tag.
>>
>> I did not choose end_date=-MM-DD because that tag would imply that
>> the service on the given public transport line will end -MM-DD but
>> that's wrong. timetable:valid_until=* is intended to be an expiry tag
>> (i.e. you don't have to check this OSM object until -MM-DD.
> 
> timetable:end_date=* would be better than a new tag of valid_until=* ?

I am ok with using timetable:end_date=* instead of
timetable:valid_until=*. But I am not ok with valid_until=* because it
implies that the service on the given line will end on the given date.
But what I want to express is the validity of the timetable the route
relation is based on.

>> Unfortunately, sometimes timetables or operators change not only in
>> December but also in June. New (railway) lines or stations are not
>> always opened at the great timetable change in December. There are
>> frequent cases when (smaller) stations are opened in the course of the
>> year.
>>
> The unscheduled changes will also occur with timetable:end_date=*, or
> similar.

If a new halt on a line is opened in the course of the year, the route
relations has to be modified on that date. If a mapper knows that a new
halt will be added before the next timetable change (sometimes
timetables have nots like "halt X is not served until "), he
could/should set the timetable:valid_until=* to the planned opening date
of the new halt.

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Feature Proposal - RFC - Public Transport v2 Vehicle Type "coach"

[Michael Reichert]

Hi Martin,

Am 2017-10-06 um 09:51 schrieb Martin Koppenhoefer:
> what I forgot to conclude: as the values are mostly new, and it’s not an 
> access restriction, I’d use a different key for this, rather than bus you 
> could use something like route:scope or route:type etc.

Some people (including myself) started using service=* for train routes
about two to three years ago. The service=* tag was part of the Oxomoa
Schema. Why not using this tag with different values for bus routes?

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Mapping of Subway Stations

[Michael Reichert]

Hi Ilya,

Am 25.09.2017 um 09:46 schrieb Ilya Zverev:
>> Am 2017-09-24 um 10:49 schrieb Ilya Zverev:
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Metro_Mapping
>>
>> I don't understand what's the aim of your "proposal". There are almost
>> no new tags. Is it intended as a write-up of what could and should be
>> mapped and tagged and how that should happen?
> 
> The proposal indeed does not introduce any new tags. But it proposes a
> tagging schema that has not been documented anywhere in the wiki. I
> framed it as a proposal to get opinions of other mappers and to make it
> a written standard on metro mapping, so I could link to it people who
> map their subway.

Could you please highlight what's new and what's just "the context"?
This makes it easier to decided what the voters vote on and it will be
clear to future readers what was voted on and what was just explanation.
Yes, it might sound like writing something formal but people will quote
this proposal in future saying "community accepted this proposal".

> Also it would be a handy guide for software authors that want to make
> use of our data. Having looked at the state of metro systems, I can
> safely say that no single app had been using our subway data for
> anything but highlighting ways in route relations.

If you propose a wiki page which should serve as a handy guide for
software authors, you could just write it, mark it as draft and ask for
comments on this mailing list if you are not sure or. If the there are
different opinions, you could summarize them. I still don't see any need
to use proposal process.

> And I think, subway mapping is exactly the case where stop_area_group
> relations are useful. Because not each of 157 metro systems has an
> openly licensed GTFS feed providing these virtual connections. And it is
> not hard to provide these in OSM, just by creating stop_area_group
> relations. You cannot derive these from footways either, because only a
> few cities have that thoroughly drawn stations, and even these are not
> mapped consistently. This task is definitely not solvable by a computer
> programme — believe me, I tried. Had to do a lot of manual fixing
> afterwards.

What about declaring stop_area_group relations as an interim solution
until the platforms of all its member stations are routeable?

> Interchanges are not suggestions, they are clearly defined in the
> proposal and quite prominent on any subway maps. With your arguments you
> can build a case for dismissing stop_area relations, and also highway
> route and waterway relations.

Are we allowed to use these subway maps?

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Feature Proposal - RFC - Public Transport v2 Vehicle Type "coach"

[Michael Reichert]

Hi Ialokim,

Am 04.10.2017 um 05:36 schrieb Mikolai-Alexander Gütschow:
> I've elaborated a proposal for the route=coach tag according to the
> Public Transport Scheme v2 and as already in use in some cases.
> 
> See
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport_v2_Vehicle_Type_%22coach%22
> 
> 
> The proposal adds the possibility to differentiate between city bus and
> coach routes.

I appreciate your interest in improving the tagging of coach services
but I would not use route relations. As pointed out by Colin Smale on
the Talk page, I would just use a relation which contains the
stops/platforms. If there were no fix assignment between a line and one
or multiple platforms on a large bus station, adding the area/node of
the bus station to the relation would be better. I don't know which
value for the type=* tag should be used instead of type=route because it
is no collection of highway segments any more.

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Proposed deletion of wiki pages about motorcycle_friendly=*

[Michael Reichert]

Hi Yves,

Am 04.10.2017 um 17:44 schrieb Yves:
> Whatever this tag is good or bad, it's not a good idea to delete the page 
> from the wiki. 
> If I find it in the data, this page will inform me on its meaning. 
> Now if it's bad, you can trust the contributors not to use it. 
> Also, you can take time to explain your argument against in the discussion 
> page, it's a wiki ;-) 

I myself did not propose a deletion of the proposal page. I just
proposed to delete or move the feature pages. If the feature pages were
deleted, the internal search engine of the wiki would still return the
proposal page. I think that a proposal page is enough for a tag which
received lots of criticism and whose "inventor" ignored rule repeatedly
and tried to hide warning boxes and negative comments.

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Mapping of Subway Stations

[Michael Reichert]

Hi Ilya,

Am 2017-09-24 um 10:49 schrieb Ilya Zverev:
> I had a task of extracting subway infrastructure from OpenStreetMap, and
> I found out that some things cannot be mapped at all (e.g.
> interchanges), and some are unclear or mapped differently in different
> countries.
> 
> Please consider this proposal that clarifies tagging and mapping of
> subway stations:
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Metro_Mapping

I don't understand what's the aim of your "proposal". There are almost
no new tags. Is it intended as a write-up of what could and should be
mapped and tagged and how that should happen?

It is a good write-up, it gives a good overview but does not answer the
questions of the differences between railway=subway, railway=train,
railway=light_rail and railway=tram.

I am not against a long and structured write-up for mapping public
transport but I would prefer if people would invest the time into
cleaning up existing pages on the wiki. There is already an overview
page: https://wiki.openstreetmap.org/wiki/Public_transport
I started cleaning it up (based on the German version which was cleaned
up and reviewed more than a year ago).

> I have already started improving the mapping of several metro systems in
> different cities. Mostly that involves adding stop_area and
> stop_area_group relations.

I thought that stop_area_group is a dead branch of the "Oxomoa" public
transport tagging scheme which influenced the current tagging scheme (I
prefer the term PTv2 – Public Transport version 2 – for it), isn't it?

> Adhering to this document would greatly simplify using subway data from
> OpenStreetMap in applications — both for multi-modal routing and for
> formatting pretty schemes.

That's a goal everyone had who wrote a tagging guide or proposal for
public transport. The key problem is a lack of guidance by tools using
the data. While other topics have lots of map styles/routing engines and
quality assurance tools, public transport has only very few tools which
are up to date and still maintained. (I currently work on public
transport validator)

https://wiki.osm.org/wiki/Proposed_features/Metro_Mapping writes:
> If you know the location and length of a platform for a subway station, map 
> it as a way Way. Using a node is pretty meaningless, and drawing a platform 
> as an area is an overkill, though possible. You can see an example of such 
> thoroughly drawn platforms here. 

A way is better than nothing but if a mapper is able to draw an area
because the station is pretty simple or he used a laser distance meter
[1], this should not hinder him to draw an area.

https://wiki.osm.org/wiki/Proposed_features/Metro_Mapping writes:
> The modern public transport tagging schema introduces stop positions: points 
> on rails where trains actually stop. These should be placed in the middle of 
> a hypothetical train, that is, near the center of the platform.

Adding them always near the centre of the platform is wrong and useless.
A machine could that do, too. From my point of view they should be added
where the centre of the train is. If a platform is three MU long but
trains are only three MU long during peak hours and short trains stop
near one end of the platform, the stop position node should be located
where the centre of the shortest train will be. Many train, tram, subway
and light rail systems have signs in the track or along the track which
tell the driver where to stop depending on the length of his train. This
signs can also be used by mappers and passengers who know how to
interpret them.

https://wiki.osm.org/wiki/Proposed_features/Metro_Mapping writes:
> When it is possible to go from a station to another station without leaving 
> the metro system, that is, without passing a railway=subway_entrance node, 
> these stations are considered to be in an interchange. To mark it, create a 
> public_transport=stop_area_group relation, and add stop_area relations (not 
> station nodes!) of all stations that are part of the interchange. 

I am not a fan of stop_area_group relations. They tend to be collective
relations (like stop area relations). The practical use of
stop_area_group relations is limited.

Classic public transport routing engines need a manually produced set of
"virtual" connections between two stations which are within a walkable
distance, e.g. from Weinheim(Bergstraße) to Weinheim Hbf [2] because
they only calculate routes based on the timetable. Nowadays multi-modal
public transport routing engines are available, even as open source
software. That's why I think that any suggestions for interchanges
should not be mapped. It is a problem which solveable by a computer
programme. Suggestions are non-factual information which do not fit into
the goals of OpenStreetMap which is based on facts.

Best regards

Michael


[1] https://youtu.be/5T5zH-zanXI?t=10m48s
[2] https://www.openstreetmap.org/#map=17/49.55290/8.66625

-- 
Per E-Mail kommuniziere ich bevorzugt 

Re: [Tagging] Proposal: "slogan" tag. Opinions?

[Michael Reichert]

Hi,

Am 2017-09-19 um 09:32 schrieb Topographe Fou:
> From my understanding it would open even more the door to advertising and I 
> don't see any added value from a map point of view (no usefull data for the 
> user).
> 
> Moreover, in your exemple, I don't see the point to repeat on all McDonald's 
> the same tag. A separate database with brand data would fit more your need 
> (Wikidata?).

+1

We already have the "problem" that companies whose business is adding
shops/restaurants/etc. to all the map providers add their clients to OSM
which itself were no problem if they don't add lengthy, non-factual
description=* tags. OSM is a project to collect facts. Slogans are not
facts and I myself don't love McDonald's.

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Feature Proposals - RFC for multiple features - Education Reform - Magnetic Levitation Trains

[Michael Reichert]

Hi Erkin,

Am 17.09.2017 um 07:54 schrieb Erkin Alp Güney:
> Two RFCs by me are ready. One of them are education reform(actually
> delayed a bit). This brings education key instead of amenity=school.
> Full proposal at
> 
> Another is magnetic levitation trains, this one having completed its
> draft quickly. This brings railway=maglev tag and its associated
> rendering. 
> 

Could you please write two separate emails to the mailing list for two
proposals (i.e. write an additional email for your maglev proposal)?
Otherwise there is not clear distinction between the propoals in the thread.

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] highspeed=yes

[Michael Reichert]

Hi,

sorry for the late response on the mailing list, I accidentially send
the email only to Richard.

Am 11.07.2017 um 10:49 schrieb Richard:
> without a proper definition there is no way to resolve your dispute
> and the tag is unverifyable and of limitted use as is.

There are two open questions regarding the definition:
- What qualifies a track to have highspeed=yes? Minimum speed, curves,
type of traffic, fencing, train protection etc. are the relevant
factors. But it has not been decided yet which of them are relevant and
which are more important.
- If a track qualifies to have highspeed=yes, should the whole line
(including the slow sections at its beginning and end where it leaves
the older parts of the network or runs through existing stations) get
highspeed=yes?

I would like to keep the discussion to the second question.

Fliefy uses highspeed=yes for tracks with at least 200 kph. I agree with
that. But other mappers disagreed when we discussed that in real life
the last time. That was three years ago.

There is a plenty of examples of potential highspeed=yes on not-so-fast
tracks:
- The stations Fulda, Kassel-Wilhelmshöhe and Göttingen (all along high
speed line Würzburg–Hannover). Speed limit is about 100 to 140 kph for
trains passing these stations intentionally.
- The tracks at most junctions of the old and new railway line from
Karlsruhe to Basel are part of the new high speed line. Where the two
lines separate, the speed limit is 100 kph because these junctions are
of temporary nature and they did not want to spend much money for
expensive high speed points. Once the whole line is finished (in about
10 to 20 years), they will be removed. Btw, the speed limit on the old
line is 160 kph and 250 kph on the new line.
- The high speed line Leipzig–Nuremberg runs through Erfurt Central
Station on its own tracks but with a speed limit much below 160 kph
(outside the station and its surrounding 300 kph).
- The Northeast Corridor between Washington and Boston has sections
where the train is "slow" (changeset discussion I linked in my initial
posting).

Should all those junctions and stations and the other parts of the line
get highspeed=yes although they are not suitable for high speeds? If
yes, this would open a new discussion where the line should begin and
end. Its a decision which is difficult or impossible to research *on*
*the ground*. I would like to avoid that.

> Presumably when exact speed limits will be mapped in the ideal case
> what is the use of this tag? 

Different countries define "high speed" different. In most countries
high speed traffic needs a more sophisticated train protection system.
The maximum speed of the less sophisticated train protection is often
but not always the border between "high speed" and "not high speed"
because the railway operators introduced the better train protection
system when they build their first high speed lines.
Countries with a large high speed network might set the limit higher
while countries with a smaller (or slower) one might set the limit
lower. The first one might be France, the second UK. Swiss railway staff
would experience 200 kph as fast (Olten—Bern, New Gotthard Tunnel). Do
we have fix definitions of highway=* all over Europe? No, we don't. Just
compare highway=trunk in UK with German highway=trunk.

Map style authors are happy to render high speed network maps without
checking the location and the local definition of each line to be
rendered. The tag highspeed=yes is intended to be the extension of
usage=main/branch upwards. An early version of OpenRailwayMap tagging
scheme in 2011 suggested to use usage=highspeed but others argumented
that a high speed line is usually a main line.

The more vague a definition is, the more happy data consumers are if OSM
contributors do the classification.

> Just to say that it is called "Hochgeschwindigkeitsstrekce" in German, 
> or is there something more implied like special traffic rules, special 
> signaling, freight train exclusion?
> Perhaps all this properties should be tagged in separately?

Most of these properties are all tagged separately:

- Train protection using railway:=yes/no [yes, this scheme
is not a well designed tagging scheme]
- Speed limit using maxspeed=* and maxspeed:*=*
- Usage is difficult to tag and derive from OSM. There is
railway:traffic_mode=freight/passenger/mixed but one regular freight
train is enough to use "mixed". Types of passenger trains (local vs.
InterCity vs. high speed) are mapped as route relations but then you
have to parse and understand ref=* because service=* is not mapped on
all route relations. Germany has a handful of real high speed lines (>=
250 kph) which are used by local trains, too.
- Fences are mapped as you would map them.  It is difficult and not
effient to determine if a railway line is fenced. In addition, mappers
in rural areas have more important things to map than fences along a
railway line in the middle of nowhere. Btw, older high 

Re: [Tagging] highspeed=yes

[Michael Reichert]

Hi Martin,

Am 11.07.2017 um 01:27 schrieb Martin Koppenhoefer:
>> On 10. Jul 2017, at 23:42, Michael Reichert <naka...@gmx.net> wrote:
>>
>> The main question is:
>> Shold the whole line (the definition of "line" is a different discussion
>> worth) get highspeed=yes or only the parts which are suitable for high
>> speeds due to large curve radius, special signalling and train
>> protection etc.? What is your opinion?
> 
> 
> What is a "line" in osm tags?
> If you map a specific train connection (route=train) it would apply to the 
> whole thing, if you tag a piece of rail (route=railway or railway=rail) I 
> would only put it on those parts that are suitable for highspeed trains.

Line in this context refers to all railway tracks between two stations
except sidings, yards, spurs etc. (i.e. all tracks which would get usage=*).

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

[Tagging] highspeed=yes

[Michael Reichert]

Hi,

I have a small dispute with user flierfy about the usage of
highspeed=yes and would like to ask for your opinions. [1]

I think that highspeed=yes should only be use that tracks whose speed
limit is above a certain minimum speed (On The Ground Rule). The speed
might vary between countries.

flierfy thinks that the whole railway line should be tagged from its
beginning to its end if it contains one part which qualifies for
highspeed=yes.

Example:
The railway line from Leipzig to Dresden clearly qualifies [2] for
highspeed=yes between km 4.0 (near Leizig-Sellershausen) to km 23.8
(near Bennewitz) and from ~ 30.2 (between Wurzen and Kühren) to 59.6
(between Bornitz bei Oschatz and Riesa). Only on these two sections
trains may run faster than 160 kph (limit is 200 kph there). Other
sections have speed limits between 100 kph and 160 kph. Flierfy tagged
the whole line with highspeed=yes.
http://www.openrailwaymap.org/?lang==51.33372202647613=13.089437484741211=13=standard

The high speed line might be completed on one day in future but it will
takes years, many years.

The wiki pages Key:highspeed, DE:Key:highspeed and
OpenRailwayMap/Tagging at OSM wiki do not mention whether the tag should
be used for the whole line or only for the parts whose speed limit is
"high". In difference, DE:OpenRailwayMap/Tagging has contained the
additional sentence that the whole line should get highspeed=yes. That
sentence was added by user rurseekatze on 2015-12-29 [3]. I don't
remember a discussion about it on a mailing list. Fliefy refers in the
changeset discussion between us to DE:OpenRailwayMap/Tagging.

The definition of this tag was discussed on a meeting of railway mappers
in Cologne in July 2014 but we did not find any consensus there and left
it unmodified.

In March 2015 a mapper attempted to add highspeed=yes to the Northeast
Corridor from Washington to Boston. After 25 comments in the changeset
discussion the tag was removed.
https://www.openstreetmap.org/changeset/29723896

The main question is:
Shold the whole line (the definition of "line" is a different discussion
worth) get highspeed=yes or only the parts which are suitable for high
speeds due to large curve radius, special signalling and train
protection etc.? What is your opinion?

Best regards

Michael


PS I invited fliefy to join this mailing list on Friday and waited with
posting my question until today to be fair.


[1] changeset discussion in German (just for reference):
https://www.openstreetmap.org/changeset/50067730
[2] assuming that high speed in Germany means 200 kph or faster. Other
countries might have other limits.
[3]
https://wiki.openstreetmap.org/w/index.php?title=DE%3AOpenRailwayMap%2FTagging=revision=1256039=1238373


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)




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

Re: [Tagging] rail routes and stations (rail question 1)

[Michael Reichert]

Hi Martin,

Am 2017-05-12 um 12:46 schrieb Martin Koppenhoefer:
> btw: the current railway=station tag definition doesn't say anything how to 
> differentiate between freight stations and passenger stations and possibly 
> combinations of both.
> 
> Which tags are used?

As a railway mapper, I must admit that there is no tag to indicate that
a station with railway=station is a passenger-only station. The opposite
is possible to tag, use railway=yard.

This is a "hole" in the railway tagging and you are free to invent a new
tag.

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] rail routes: how are platforms and stops associated (rail question 2)

[Michael Reichert]

Hi Bjoern,

Am 2017-05-11 um 11:17 schrieb Bjoern Hassler:
> in the case of 4a/4b etc I would put in different stop points. If 4a always
> serves one route, then 4a would be added to the route relation. Maybe if 4a
> / 5a / 6a can all serve the same route, then I don't know what the solution
> is Maybe you just add a new stop point somewhere, and add a note? Or
> put 4a/5a/6a into a relation, and add the relation? (That would be against
> the spec at the moment I think... but could be a solution.)

If some trains of a line serve platform 4, some 5 and some 6, only map
the variant which is served most frequent on a working day or over a
week. In some countries the platform where a train stops is announced
only a few minutes before its arrival (e.g. in France and Czech Republic).

> Colin: Actually, in the case you mentioned (short/long trains), I guess
> there could also be several stop points. I think that's not a problem. It's
> just you would only add one of those to the route relation. For the several
> stop points, ideally there would be a note, saying "front of train, 4
> carriages" or "front of train, 8 carriages", or maybe an additional tag of
> some kind.

Just map the location of the center of the shortest train which serves
this route. This will lead passengers always to the location on the
platform where they most probably can enter a train.

> To come back to the original question: If an association between a stop
> point and platform exists (as it does on the underground), is there a way
> of indicating this through tagging? What are your views?
> 
> There are a few possibilities, e.g. both the stop point and the platform
> could share the same name (kinda fragile though). They could be ordered in
> the relation so that the stopping_position comes first, followed by the
> platform (this would be a new feature, but e.g. a tag could be added to the
> route relation where this ordering has taken place). Also, the roles in the
> route are stop/platform, but also suggest stop:n / platform:n. It's not to
> order them, and it doesn't look like this is to associate stop/platform,
> but it could be used.

Valid PTv2 route relations are ordered, i.e. the platform which follows
a stop position and is near the stop position always belongs to the stop
position.

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] rail routes: how are platforms and stops associated (rail question 2)

[Michael Reichert]

Hi Bjoern,

Am 2017-05-11 um 12:08 schrieb Bjoern Hassler:
> Basically, I'm trying to understand
> https://wiki.openstreetmap.org/wiki/Relation:route#Members. There's the
> concept of station vs. stop_position, in case there are many stop_positions
> in a station / stop_area. Sorry for London examples, but I'm trying to get
> to grips with TFL. So e.g. King's Cross is a station/stop_area, but with
> multiple stop_positions (for underground, busses, main line, etc).

The wiki page Relation:route is an overview over all types of route
(hiking, cycling, ferries, trains, …). In addition, the public transport
part seems outdated. If you were able to read German, I would suggest
you to read DE:Public_Transport which describes the current status of
public transport mapping (its English counterpart is outdated, too).

> In 'Members', there a node with role "stop"/"stop:n", described as follows
> "A bus stop or train halt, on the route. The order of the members in the
> relation should be identical to the order in the timetable. The number is
> not needed to preserve the order of stops. It is only a guide to help
> mappers finding missing or misplaced stops. You can use stop instead, if
> you like."

"stop:n" is totally outdated and was necessary at times when relations
were not ordered list (AFAIK OSM API v0.5).

The proposal page
https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport
is AFAIK the best English documentation.

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] rail routes: how are platforms and stops associated (rail question 2)

[Michael Reichert]

Hi Bjoern,

Am 2017-05-10 um 18:59 schrieb Bjoern Hassler:
> In an  osm:relation:route
>  (type=route,
> route=train/...), you have both platforms and stop positions. How is a
> particular platform associated with a stop that serves it?
> 
> E.g. for public transport routing, you'd walk (highway=footway) to a
> platform (public_transport=platform), at which point you'd change to a
> train stopping at a stop (public_transport=stop_position). How would the
> routing algorithm know that the platform is associated with the stop?
> 
> Is there an existing mechanism or convention, e.g. a tag on the platform
> that indicates the stop, or both tagged with the same name or similar?

Stop positions can have a tag ref=* or local_ref=* giving the track
number which is signed on the platform. The platform has ref=*, too. The
ref tag of the platform often contains multiple numbers because many
platforms have to edges, i.e. ref=2;3 or even worse: ref=2a;2b;2;3a;3b;3
(if the track can be occupied by two trains behind each other at the
same time – very common at busy stations).

If you don't want to parse ref=*/local_ref=* and route relations are
properly mapped, you can check which route relations reference a
platform. If a route relation contains both platforms and stop
positions, the next member of a relation after a stop position node is
should be the platform.

I think that both variants provide better results than simple snapping
on the next edge in your pedestrian routing graph (if platforms are in
your routing graph). There are cases in reality where a railway track
has platforms on both sides but you can or must leave the train only to
one direction.

> PS I've noticed that sometimes the stop position is at the far end of a
> platform (i.e. the two stop positions are at opposite ends of the station).
> Maybe that's so that an association can be made?

From my point of view this is wrong mapping. (In Germany mainly done by
user rayquaza) To give a correct answer, you should give some examples
(node IDs).

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)




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

Re: [Tagging] rail routes and stations (rail question 1)

[Michael Reichert]

Hi,

Am 2017-05-12 um 08:07 schrieb Martin Koppenhoefer:
> this was closed as duplicate, so they are aware there is an issue.
> In the discussion the only argument (by Nakaner, a rail enthusiast)
> is that there are 3 different legally relevant areas for train
> stations in Germany, so the German railway community has decided
> not to map any of them but use a node instead. Seems logical to
> you?

There was a discussion about mapping station areas on the Tagging
mailing list in October.

https://lists.openstreetmap.org/pipermail/tagging/2016-October/030301.html

Best regards

Michael (Nakaner)


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.
(Mailinglisten ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Feature Proposal - 2nd RFC - Improve Toilet Tagging

[Michael Reichert]

Hi Micah,

Am 2017-04-14 um 18:49 schrieb Micah Cochran:
> I've rewrote the proposal for improving toilet tagging.  This is a second
> request for comments.
> 
> Now this proposal tags for occupancy (single or multi), gender/group
> designation
> of toilets that are within a place (where tagged "toilet=yes"), and a
> prefix tagging scheme that will make the tags only apply to a
> group(gender) designation
> toilet.  (For example, it allow you to be able to tag that there are
> urinals in the men's room, but not the women's room.)
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Toilet_Tagging_Improvements
> 
> Please put comments in the proposal's discussion section.

The wiki page currently contains many paragraphs which are struck out.
Could you please delete them because they are no longer proposed by your
proposal? The OpenSTreetMap Wiki has a version history of each page
which shows you who edited the page at which time.
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Toilet_Tagging_Improvements=history
That's why I think that the section "Revision Notes" is also not necessary.

You can add a link to the previous discussions on the mailing lists
which are the reason for the changes of your proposal. That would be
great for people in future who want to understand your changes and why
things are as they are.

Best regards

Michael



-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] The direction=* tag

[Michael Reichert]

Hi,

Am 2017-03-16 um 05:13 schrieb Tod Fitch:
> The “direction” tag [1] has different uses that seem disjoint to me.
> To specify the orientation (compass point or degrees from north) of an object 
> (adit or cave entrance, etc.). 
> To specify direction (clockwise/counterclockwise) around a roundabout (not 
> sure why this is needed as it should be apparent from local laws or specified 
> with a “oneway=yes”).
> To indicate the direction (forward/backward) a stop or yield (give way) sign 
> has effect along a way.
> Oddly, that third use seems only for stop and yield signs but not for traffic 
> signals where a “traffic_signals:direction=forward | backward” tag is to be 
> used. However that seems to be the most used form [2]. Apparently some have 
> figured that if we have “traffic_signals:direction” there should be 
> “stop:direction” [3] and “give_way:direction” [4] tags.

A direction tag is also used for railway signals, it's called
railway:signal=forward/backward/both. Both tags were used the first time
end of 2011 when the development of the current railway signal tagging
scheme started.

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] simple 3D buildings, proposed redefinition of building:levels and building:min_level for building:part

[Michael Reichert]

Hi Martin,

Am 09.03.2017 um 19:39 schrieb Tobias Knerr:
> Your proposed change would, therefore, make data mapped using these keys
> mostly useless due to the unresolvable ambiguity. In my opinion, that
> kind of cost is not worth it.

I oppose the proposed change for exactly the same reasons. Redefinitions
like this just cause confusion amongst mappers and data users. As a
consequence, mappers will focus on other topics than 3D mapping. Is that
your goal? I hope not.

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Discouraging frequency=* on power lines and cables

[Michael Reichert]

Hi David,

Am 09.03.2017 um 06:35 schrieb David Marchal:
>> Le 8 mars 2017 à 23:04, Michael Reichert <naka...@gmx.net> a écrit :
>>
>> Please keep OSM simple. I don't want to add a power route relation on
>> every tiny minor distribution line/cable (230 V).
>>
> Totally agree with that. I don’t understand the usage of a relation binding 
> the distribution network elements: the connections between them can be 
> retrieved from the nodes and ways, and the relation would merely be use for 
> group tagging. IMHO, the relation would only make sense for transport lines, 
> which are often viewed and treated as continuous, even if their 
> characteristics change along their path (overhead, underground…). At a 
> distribution level, however, this sounds overkill to me.

I am not against the usage of power route relations in general. There
are lots of cases where they are useful. The Elbekreuzung 2 (Elbe
Crossing 2) is a simple and nice example why they are necessary: Most
cables of that line are 380 kV AC but four of them are used by DB
Energie GmbH for their 110 kV 16.7 Hz to supply traction current for the
electrified railway line(s) in Schleswig-Holstein.
https://en.wikipedia.org/wiki/Elbe_Crossing_2

I just don't like the necessity to add route relations to every power
line just to indicate its frequency.

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Discouraging frequency=* on power lines and cables

[Michael Reichert]

Hi François,

Am 2017-03-08 um 15:18 schrieb François Lacombe:
> frequency=* tag aims to qualify active elements on telecom or power
> networks (among others, see wiki
> http://wiki.openstreetmap.org/wiki/Key:frequency)
> 
> I see it as an optional property of power lines or cables.
> http://wiki.openstreetmap.org/wiki/Tag:power%3Dline
> 
> In practice, a physical line/cable section isn't operated at, nor designed
> for, any dedicated frequency but it's all about the supported power circuit
> (a logical relation going from a place to another place through the grid).
> It always exists if line is actually powered on.
> We use to map such logical circuits with route=power relations where
> frequency is more relevant.
> 
> Can we drop frequency on power lines and cables wiki page ?
> It can't be guess by looking at the line (instead of voltage) in landscape
> and there may be inconsistencies between circuits relations and lines
> members.

frequency=* should not be deprecated (if that is ever possible at OSM at
all) or removed from the wiki page because otherwise mappers are forced
to add a useless relation on every single power line. If you map a power
line, you usually know its frequency. For example, 50 Hz is the default
frequency in Europe. If the line belongs to the separated 16.7 Hz
network, it is signed (signs with the name of the operator, e.g. DB
Energie GmbH at the towers).

Please keep OSM simple. I don't want to add a power route relation on
every tiny minor distribution line/cable (230 V).

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)




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

Re: [Tagging] Fwd: Feature Proposal - Voting - tag "motorcycle friendly" for accomodations

[Michael Reichert]

Hi Martin and others,

Am 2017-03-06 um 17:37 schrieb Martin Koppenhoefer:
> yes, that wording is unfortunate, because in most/many OSM mailing lists
> messages never get approved. I am myself admin of a very small regional ML
> and from time to time there are periods where a lot of spam arrives, I can
> imagine checking held back messages in the big lists would be a lot of work
> (and mostly consist in rejecting spam). You would also have to do it daily,
> because after some time many messages will seem out of context.

I have changed the wording of the wiki page Proposal_Process today to
stress the necessity to subscribe the Tagging mailing list. Feel free to
modify/revert it if you don't like it.

https://wiki.openstreetmap.org/w/index.php?title=Proposal_process=history

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Fwd: Feature Proposal - Voting - tag "motorcycle friendly" for accomodations

[Michael Reichert]

Hi David,

Am 05.03.2017 um 23:46 schrieb David Bannon:
> Maybe its time someone put a note on the proposal page saying that the
> author is posting to the list but does not appear to be receiving
> messages from it ?
> 
> In case its a language issue, could that message be in German and
> English perhaps ?

I got an answer from Thilo in English although I wrote him in German.
[1]The English did not look like Google Translator translating German to
English. ;-)

Best regards

Michael



[1] He uses the German locale on his computer and a gmx.de email
address, so German seems to be his preferred language.


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Invalid voting of proposed feature motorcycle_friendly=*

[Michael Reichert]

Hi,

Am 2017-03-04 um 15:02 schrieb Martin Koppenhoefer:
> mapping this kind of information (e.g. michelin star restaurants ) in a 
> structured and systematic way is likely forbidden because it means recreating 
> a (probably) proprietary db 

IMHO this is the only way who the friendliness of a POI towards
motorcyclist, cyclists etc. should be mapped at OSM because it is very
objective (just have a look at the entrance door of the POI if there is
such a label/sign or not).

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

[Tagging] Invalid voting of proposed feature motorcycle_friendly=*

[Michael Reichert]

Hi,

I have been informed by another mapper who uses XING (the German
LikedIn) that there is a new tag motorcycle_friendly=yes. [1]

Its wiki page says that the key has been proposed and accepted.
https://wiki.openstreetmap.org/wiki/Key:motorcycle_friendly
The proposal page can be found here:
https://wiki.openstreetmap.org/wiki/Proposed_features/motorcycle_friendly

The RFC was announced on this mailing list on January 10, 2017.
https://lists.openstreetmap.org/pipermail/tagging/2017-January/030844.html

If you have a slight look at the proposal box at the top of the proposal
page on the wiki, you will discover that the RFC phase was only one week
although the proposal "guideline" says [2]:
> At least two weeks after the RFC, and once problems brought up in
> discussion have been resolved by modifying the proposal, send out a
> Request for Voting to the tagging mailing list

In addition only the RFC was announced at this mailing list but the
voting has not been announced. Therefore it is no surprise that the
proposal was "accepted" by 13 users and only 3 users opposed.

I think that most of these users are friends of the user who proposes
the tag because they only have one edit at the wiki – their voting for
this proposal.

Because the proposal violated the guideline, I would like to
- remove the status "proposed" from its feature documentation page
- reset the status of the proposal to "RFC"
- to declare the voting as invalid by adding a note at the top of the
voting section
- add a note to the feature documentation page linking to this email and
explaining that the voting was invalid.

What is your opinion?

Best regards

Michael


[1] XING users can open the link:
https://www.xing.com/communities/posts/fuer-die-motorradfahrer-unter-den-mappern-pois-1012765773
[2] https://wiki.openstreetmap.org/wiki/Proposal_process#Voting

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Tagging speed camera *zones*

[Michael Reichert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Rory,

Am 2017-01-17 um 13:39 schrieb Rory McCann:
> On 16/01/17 17:56, Michael Reichert wrote:
>> Are there signs along the road which inform the car drivers that
>> there might be a mobile speed camera van?
> 
> Yes there are.

If there are signs which mark the beginning of such a section but no
signs which mark their end, you could map the signs as a node on the
way with direction=forward/backward. Both in OSM and in reality data
users have to guess how long the section will be. OSM should stay to
its on-the-ground rule.

If there are both start and end signs, I would simply split the road
at the beginning and end of that section and add a special tag to the wa
y.

Best regards

Michael

- -- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.
(Mailinglisten ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEEpEt6LbLCOucBPQEHzsb2swIzIgFAlh+FT8ACgkQHzsb2swI
zIg01A/9HQgNvFN9XYhmde3v1so/kFQ/IjgxLiOf2bE14vwvSrJ971HchvjHIxWc
PaOz+yFUTiJWVaFH0rsuaJecfPJLDFt012HTw5R20v21/bE/E5LheEHVuK9dfSFN
lqOKKKCisbrjQpwyYr5PTESD1AyQ69ZHLcUscsKnz94wBCCIMvRJJVOwOjshsOMB
GJRrUQ8XPEoV+6+6ujOXJMZ627T0syzvNTTtFlqG3nU8flajYrUyB4bVkLYUZ5eT
+Yq9XAtTG/NJPm0tHcsq/LHpW16ekk/n/Urk1WCyeyEU4ivadUIWQW1KhN55aZQK
1DN0cwYo3DhN7hfkXmY6Rx56CKxqaBjwhXbAhjhyzlDonk2IZ4klw8khXAiWU9Lv
WBVmThyQZhewfdXiPgFa1f5ElkSO2z6fem07PoC61DixUAacezHfv7/FMjviiNRq
fajFeCkm6qBaTvExnI4CR5hw+gRbG47B+CJCBc4n1HQuPFUj/jbMB9n6rBpi47SM
SVi1uM1pn2s9wnIh9zG4HDOdImj9SSit3BCmE3X7KGWHEYvx+s/01hPvhpFOzVPt
/ztyYDInfDfAqj34FfMl8cBwqMQTfGcB23K3TjZ1oErE0tFk6DCapEIilweH/H57
nn+NsOnXgJ91RpgEYRmPNdN63gfBLGkpOfmjDLd/ZVevKVWng98=
=depH
-END PGP SIGNATURE-

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

Re: [Tagging] Tagging speed camera *zones*

[Michael Reichert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Rory,

Am 2017-01-16 um 17:24 schrieb Rory McCann:
> In Ireland, there are several roads which could have a mobile
> speed camera van. We have some open data from the government of
> these roads, and we'd like to map them in OSM. Ideally satnav apps
> would tell the driver that they are on a "possible speed camera van
> zone" when giving directions and the like. Many apps show warnings
> of single point, fixed speed cameras already.

Are there signs along the road which inform the car drivers that there
might be a mobile speed camera van? If not, they should not be mapped
at OSM because we only map permanent features.

As the data is provided as open data by a third-party source, app
developers can merge OSM and speed camera zone data on their own.

Best regards

Michael


- -- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.
(Mailinglisten ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEEpEt6LbLCOucBPQEHzsb2swIzIgFAlh8+z4ACgkQHzsb2swI
zIiJlw//SffWluXQXsDoVkH4pxCEkqKmyJs2XnqN5X9vs4E5RPP1YCwP2q4+u8T/
VzMlE4wGSL0briJfNIJUW9BOPPxk+ujW0EKNfXEpFvXkflRwrKXlY2qW2wAmp7Qm
T7PyOx2JE4Wm3gijCrIo73wP6xblb/jXa5gv44DPwdX05ARojVr4U204Vi9hF1iq
K5OII/zqv8H6+ufKgdMPAlD+7RnXEuG6adSphwZdBWE3Hmp2tCOO57IidDZK3gE6
4GLUGgRholqL0CwAB4F/FDfUEtRmgemGF2LN2ES3WQ+R7Aj9Cl64G088KmWdkXsa
RWp+WQJXynhz9ZCWDLX+zxxmnAyPfV0HRJp5jhMDHKmZAHMmOiefMiGBTK7Yr8hb
5RBNQKJKBN54T94y5GjAJlJut0+DX0gGsnoMK/QeWYydvyz/HguBj8nM0t9bS69w
1IACoHGL6cnNieFlOTeY3fE5ltboEnztlmM5pPycKPuLcM/lOoYCNKB6+ZlJOzTN
VZEalz2LG5Jc517kiXC9/94K6h2WIH8u064v6ncGCvGeZM94rE6UAdr2qEau2GG0
BWsnKZfyYRvjYkiXWOOzZUQGIk6MK2BSEJ7M5w3AuBAVEX8RAaM1tHSgf9D/RhDp
XSFuvour4y1HAT4o7RiGXD6wJkTjuF+h2KnPid8fTSsJORwe9qo=
=0QKV
-END PGP SIGNATURE-

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

Re: [Tagging] railway=rail vs. railway=subway

[Michael Reichert]

Hi Bill,

Am 23.11.2016 um 05:12 schrieb Bill Ricker:
> On Tue, Nov 22, 2016 at 10:08 PM, Michael Tsang  wrote:
>>> Oh really. Boston MBTA green line is a subway line that extends onto
>>> surface streets. Not full rail gauge iirc (though other lines are) and
>>> neither surface or tunnel curves could handle freight cars. The surface
>>> trolley portions that run down boulevard median are direct line
>> extensions
>>> of the tunnel line but do have grade crossings at boulevard stoplights.
>> Then I think it should be railway=light_rail
> 
> 
> ​and the way magically transforms to railway=subway at the tunnel porta​l

In that case, there are overground sections because of a lack of money
or because it was just not necessary (no busy city centre, no narrow
streets, …).

A subway system is *usually* encapsulated. But you should never say no
when you talk about railway infrastructure and public transport.

This looks much like a tram:
https://youtu.be/Fb3thVfqRS8?t=9m44s

This is the same line, just about 2 km away. It looks more like
railway=subway.
https://youtu.be/Fb3thVfqRS8?t=14m24s

The Hong Kong case is an execption to the "subways are totally
separated" rule because it is a metro using railway=rail tracks.

Best regards

Michael




-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] railway=rail vs. railway=subway

[Michael Reichert]

Hi,

railway=* should depend on the infrastructure only. The services which
use the track, don't matter.

Am 22.11.2016 um 15:41 schrieb Michael Tsang:
> On Tuesday 22 November 2016 11:28:00 jc86035 wrote:
>> Should a commuter rail system with rapid transit frequency but main
>> line-standard tracks be tagged as railway=subway or railway=rail?
>>
>> In Hong Kong, the MTR metro system has an "urban" set of DC 1432mm-gauge
>> lines, and another set of AC standard gauge lines (East Rail Line, West
>> Rail Line and Ma On Shan Line) connected to the Guangzhou–Shenzhen railway.
> 
> "Use railway=rail for full sized passenger or freight trains in the standard 
> gauge for the country or state.
> railway=rail is the largest railway classification, for full-blown full-sized 
> railways."
> 
> My interpretation of the above rule is that, if the section of the railway is 
> capable for running long distance trains, it should be tagged as 
> railway=rail. 
> Therefore, East Rail Line in Hong Kong is definitely railway=rail because 
> long 
> distance and freight trains also run on it.

I agree up to here.

> In my opinion, even the metro-only 
> sections of East Rail Line where long distance trains do not run should be 
> tagged as railway=rail because they belongs to the same railway with the same 
> standard.

If the metro-only sections have a wide structure gauge which would
permit long distance and freight trains to use it (tunnels wide instead
of narrow), they should be tagged railway=rail. But if the tracks can
only be used by metro trains, they should be tagged railway=subway.

Metro tunnels are usually more narrow than tunnels for full sized
passenger trains because building wide tunnels is more expensive.

> Normally I consider the nature of the train running on the railway to get the 
> appropriate railway=* value.
> 
> - Railway with long distance and commuter trains: railway=rail
> - Railway with metro services only: railway=subway

railway=subway are usually encapsulated systems which may have a
connecting track if new vehicles are delivered and both systems have the
same gauge. railway=subway systems don't have level crossings.

Finally, you cannot write a fix rules which is suitable for every
country and every city. In some cases you have to make exceptions from
the fixed rules. I think that metro-only tracks in Hong Kong should be
tagged as railway=subway even if they are connected to full-sized
railway tracks.

You can use route=subway for the route relations to indicate that it is
a metro-like service with metro-like vehicles.

> - Railway with street intersection: railway=light_rail
> - Railway mainly with tracks embedded on the street: railway=tram

+1

>> One of the standard gauge lines (Ma On Shan Line: short distance between
>> stations and low speed) was always tagged with railway=subway, but some
>> time ago I retagged the West Rail Line (commuter rail with long distance
>> between stations) with railway=subway, as well as the sections of the
>> East Rail Line without intercity train service (without asking anyone).
>> Should the lines be retagged as railway=rail, since they're not really
>> subway/metro lines?
> 
> For Ma On Shan Line and West Rail Line, there is a bit ambiguity. The trains 
> running on them are full sized passenger trains in the standard gauge, but 
> they are metro trains in all aspects, even all the technical standards are 
> comparable to main line standards. In fact, West Rail Line was planned to 
> have 
> long-distance trains and freight trains at the beginning, if this were to 
> become true, it would be re-tagged as railway=rail. However, the plan was 
> dropped and in the forseeable future only metro services would be run on West 
> Rail Line so I prefer railway=subway in this case. Ma On Shan Line is 
> designed 
> to have only metro service so it is definitely railway=subway, but because it 
> will be connected with West Rail Line so it was built to same full size 
> technical standard.

If the infrastructure can be used by full sized passenger trains, it's
always railway=rail. It's not that strange that light rail services use
railway=rail tracks. Have a look at the light rail line from Karlsruhe
to Hochstetten. It uses railway tracks which are also used by freight
trains between Welschneureuter Straße and Leopoldshafen Frankfurter
Straße (freight trains go to KIT Campus Nord, formerly Karlsruhe
Research Centre).
http://www.openrailwaymap.org/?lang==49.076789590142965=8.403253555297852=13=standard

> Even the situation of East Rail Line is not completely clear. In 1983, East 
> Rail Line was a relatively infrequent (20-minute headway in outer suburbs) 
> commuter rail service using British national railway standard, comparable to 
> S-Bahns in Germany.

S-Bahns in Germany (those operated by DB) are tagged as railway=rail [1]
because most of them share the tracks with all other types of trains
(freight, regional, high-speed). S-Bahns are normal trains and 

Re: [Tagging] Tagging of Country Names

[Michael Reichert]

Hi Warin,

Am 25.10.2016 um 23:32 schrieb Warin:
> ? You are not proposing removing all the English names from the data base?!

No, he doesn't.

He just proposes to remove the English name from the name=* tag in
countries where English is neither an official language nor a common
(but non-official) language. name:en=*, int_name=* etc. will be left
untouched.

> How they are used (rendered) is your issue.

Sometimes the developers of rendering styles discover errors in our
data. That's what happened with Sven who develops a German branch of OSM
Carto which does a phonetic transcription of non-Latin scripts into Latin.

Best regards

Michael


PS I agree with Sven's proposal as long as he acts carefully.


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Railway=station + area=yes questions:

[Michael Reichert]

Hi Martin,

Am 2016-10-05 um 10:13 schrieb Martin Koppenhoefer:
> 2016-10-04 21:36 GMT+02:00 Michael Reichert <naka...@gmx.net>:
>> https://wiki.openstreetmap.org/wiki/File:Station-asymmetric.svg
>>
>> (1) A passenger might define the station as the area around the
>> platforms, the station building, and – that's another dispute – maybe in
>> addition the bus stop and car parking. This is shown as the purple thick
>> line.
>>
> 
> 
> 
> if I understood your sketch "simple station" correctly, you see
> public_transport=station as a way of representing this, right? Anyway, with
> an extensively mapped station, a passenger could find out "his version of
> the station" by looking at all accessible footways/highways and platforms
> inside the station area.

Yes.

>> (2) Train staff and other people interested in railway operations have a
>> much larger definition of the station. It includes the whole siding and
>> yard tracks which belong to the station. Depending on the country, a
>> station begins either at the entry signal (left outermost signal in
>> the image) or at the first point a train passes when it enters the
>> station. The station ends either at the entry signal of the opposite
>> direction (right outermost signal in the image) or the last point a
>> train passes which leaves the station towards the right edge of the
>> image. This is shown as the thin rose line.
>>
> 
> 
> this is what I would use for railway=station. I guess "point" was meant to
> be "switch point"? 

Yes.

> I would prefer "switch point" for the limit along the
> tracks, because this is easy to spot on aerial imagery, easy to map,
> logical because outside of the first switch you are likely on a track meant
> to go somewhere, rather than a less important track inside the station. I
> wouldn't oppose "entry signal" neither, and I guess there is not so a big
> difference between the 2 variants. It wouldn't actually matter for my
> mapping and to get an idea how big the station is (I think, feel free to
> tell me more).

There are usually a few hundred meters left between the first point and
the entry signal. It is used for shunting movements inside the station
(i.e. an engine which is moved from one track to another) and a safety
distance to prevent collisions between shunting movements and a train
overruns the entry signal if it displays the stop aspect.

Wether the stations ends at the entry signals or at the last point
depends on the country. It is ok and the way how OSM works if a mapper
only maps the area from first to last point if he cannot spot the entry
signals on the aerial imagery (either because they are hidden by trees
or do not exist or he is not a railway mapper).

>> I think that we should use the established tag railway=station for nodes
>> only because the node will located where everyone agrees that there is a
>> station. If we tag (2) with railway=station, the centroid of the area
>> will be at a position where users would not expect it – neither
>> passenger nor railway staff.
>>
> 
> 
> If you think you will need an extra node or more, call it
> station_access_point or something similar (btw. there is a suggestion in
> the wiki to call all these railway=subway_entrance, not my favorite term
> actually, because of the word "subway"). This simple idea of putting
> floating nodes has serious limitations anyway in all cases where the
> station is more complex (e.g. access from both ends). From a logical point
> of view, it makes not sense that "railway=station" represents something
> different than a railway station, and railway stations do have significant
> spatial extent.

The problem is that railway=station has the meaning "train station for
passengers (and goods in addition)" and has been mainly used for nodes.
Therefore data users who render maps, usually calculate a centroid and
place an icon there. If we start mapping definition 2 of a train station
as an area with railway=station, these data users have to change their
map styles. Icons will get rendered at wrong locations. Search engines
will return wrong results.

https://umap.openstreetmap.fr/de/map/unbenannte-karte_105529#9/49.2597/9.5004
shows some assymetric stations.
Albtalbahnhof (the stations where light rail services to Rastatt and
Ettlingen depart) is a train station whose platforms and station
building is located at the northern end of the station. Mapping an area
with railway=station, will harm most data users.

My suggestion:
Use railway=station + name= only on one single
node. Use public_transport=station + name= on areas
which cover the station building, platforms and other features important
for passengers. Use

Re: [Tagging] Railway=station + area=yes questions:

[Michael Reichert]

Hi,

Am 2016-10-04 um 11:37 schrieb Martin Koppenhoefer:
> 2016-10-03 21:54 GMT+02:00 Alexander Matheisen
> :
> 
>> The main problem I see for mapping stations as areas is the lack
>> of defined boundaries. Compared to other types of POIs, the
>> definition of a "station area" strongly differs depending on the
>> background of the mapper and the use case.
>> 
> 
> 
> most/many stations are fenced, using the fence perimeter will
> typically give you a very good polygon approximation for a minimum
> size, especially compared to a single node with no spatial extent
> at all.

I agree with you that the extend of the area orthogonal to the direction
of the tracks is well defined. But the extend along the tracks is
different depending on the definition. Let me illustrate it with a
figure I showed at my talk at SotM.

https://wiki.openstreetmap.org/wiki/File:Station-asymmetric.svg

(1) A passenger might define the station as the area around the
platforms, the station building, and – that's another dispute – maybe in
addition the bus stop and car parking. This is shown as the purple thick
line.

(2) Train staff and other people interested in railway operations have a
much larger definition of the station. It includes the whole siding and
yard tracks which belong to the station. Depending on the country, a
station begins either at the entry signal (left outermost signal in
the image) or at the first point a train passes when it enters the
station. The station ends either at the entry signal of the opposite
direction (right outermost signal in the image) or the last point a
train passes which leaves the station towards the right edge of the
image. This is shown as the thin rose line.

If we used (1), we would exclude yard (freight) tracks near the
platforms. But I think that many passengers include them into their
definition of a station if they are located next to the platforms.
(definition 3) As an result, you will have three definitions of a station.

https://umap.openstreetmap.fr/de/map/unbenannte-karte_105414#17/48.94774/9.13638
shows you definition (1) and (2) at the example of Bietigheim-Bissingen.
All tracks in Bietigheim-Bissingen which do not have a platform, are
freight tracks. Definition 1 is shown in blue, definition 2 in red.

I think that we should use the established tag railway=station for nodes
only because the node will located where everyone agrees that there is a
station. If we tag (2) with railway=station, the centroid of the area
will be at a position where users would not expect it – neither
passenger nor railway staff. Assymmetric stations (Bietigheim is
rather symmetric) occur quite often.

https://wiki.openstreetmap.org/wiki/File:Station-asymmetric.svg

Terminus stations are a obvious example of an assymetric station. The

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)




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

Re: [Tagging] Railway=station + area=yes questions:

[Michael Reichert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Am 2016-10-04 um 11:50 schrieb Martin Koppenhoefer:
> 2016-10-04 0:19 GMT+02:00 Warin <61sundow...@gmail.com>:
> 
>> There is a nice diagram of how to map a simple station
>> 
>> http://wiki.openstreetmap.org/wiki/Tag:railway%3Dstation#A_S 
>> imple_Railway_Station
>> 
> 
> 
> I believe this diagram is completely wrong regarding the station
> area and landuse. I suggest to remove or improve it. The
> landuse=railway is not ending at the station boundaries [1]. The
> area depicted as landuse=railway is actually the railway=station
> area.
> 
> The user who made this diagram is the same who removed the
> area-icon from the railway=station article, so it is not
> astonishing he used a node only version in his diagram.

I drew the figure as an illustration of the written documentation.

Yes, landuse=railway ends in the figure at the entry signals of the
station but that does not mean that the area beyond the entry signals
must not be mapped with an additional polygon which gets
landuse=railway, too. I added them to the figure and uploaded a new
version.

A relation with type=railway + railway=operating_site could connect the
station node and the area of the station (landuse=railway polygon).

Best regards

Michael



- -- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJX8/7qAAoJEB87G9rMCMyI2ocQAJIe0qK+txpxwsADTbMbss8N
SrgyS6tA2gmlfv3anXXtG5ULjUz0ahvSI7VHw/Y4PwHMAvaIxkevcS7NIq+ca8Py
D1EOgt4WNWFB4vYofKf/Ya+rCtiROCXubZyhKS7TWz+8lTMpsLRCMkeE5/zgIHCU
lp8UstFgHvughzlGcTeamk79pKL4Kh62n0tIXqZQDsMcRlKY9FBJ/SJWl7D3rtMp
t7P1tu4wKTLqSsSomZ6n6dnktIXE9dVIqKUk73a47YmoFsg4bvMa7qZf/A6pIfVl
CVmQyvZ/MoErKW/xZiTEoXNp9Noal9Bc5H7ZBp1NBwTyOEFXM76FgBSyagR2oHmr
w7MwECw9mXnu7AYK4MSLei/IuPNvao925ZTfXYLpP36mhkSD4FnTp/vOEGwPsZen
Yn9lu0GZJ8B0k2ja7+85Md2kON07Y3zx4Ul78jcZzSglGkDCE3Cht5iuO1/csKLZ
D86ofGsn5anzwHtH0kokouW825GUvWIXkjEb12yWuT9ZYV8wKSOxmro2FwwbsosA
f/1VCo733Tm1su9uGgiKkVLU++rluiVcedZAR+Q4o9tSaX7xsa5baUyw51UEBE7b
/eS4n3QBpvRq+yXn7HHdVIQvKtB3S6qIXVH/qrk+rVZzKdu0XL0URdrThFQzNrjL
ExEKT/626jAdFxf/QT0O
=x5ix
-END PGP SIGNATURE-

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

Re: [Tagging] Feature Proposal - RFC - Through service

[Michael Reichert]

Hi Michael,

Am 2016-09-14 um 05:10 schrieb Michael Tsang:
> RFC: Through service
> 
> This proposes a kind of relation to associate different public transport 
> services to become a through service, i.e. the vehicles run through the 
> services sequentially, allowing passengers staying on board.  
> 
> http://wiki.openstreetmap.org/wiki/Proposed_features/through_service

I dislike the tagging you propose. A relation with type=route route=*
should contain only nodes and ways. Relations should only be member if
they are multipolygon relations. If you want to link multiple route
relations, please use a master route relation.
type=route_master + route_master=bus/train/bicycle

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Roads with no speed limits

[Michael Reichert]

Hi Hans,

Am 28.08.2016 um 21:35 schrieb Hans De Kryger:
> Here in Phoenix Arizona more than half the freeway off ramps have no listed
> speed limit. Does (maxspeed=none) work? I've worked hard here in the valley
> adding speed limits and when you look at the ito map it looks like no one
> added any to the off ramps when in fact most of them have been surveyed and
> they have none. How to tag them?

maxspeed=none means that there is no speed limit neither by signs nor by
any law. Therefore the speed is only limited by the power of the engine.
That's the speed limit on the motorways in Germany which have no signs. [1]

Best regards

Michael


[1] If a motorway in Germany has "no" speed limit, there is an advisory
limit of 130 kph.


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Does disused:railway=* require railway=disused?

[Michael Reichert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Am 28.07.2016 um 09:31 schrieb Warin:
> My understanding is;
> 
> The primary tag is railway=disused.
> 
> Then you have a 'sub tag' to describe what is disused .. a railway 
> station, light rail line etc.

railway=disused is a very old and established tag. All data consumers
who want to do something (e.g. rendering) with disused railway tracks,
use this tag. disused:railway=rail/narrow_gauge/tram/… is used for
further distinction because it is a huge difference if you have a
disused miniature railway or a disused monorail.

Stations, halts and other disused railway nodes are not tagged using
disused=railway because this tag is defined as a disused railway track
(a track cannot be a point feature, it's always a line feature).

Best regards

Michael


- -- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.
(Mailinglisten ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXmcJVAAoJEB87G9rMCMyII74P/jCWZHjjJPI68RFUMenRERQ/
V2dHHhR0Ass/V0Y/n1hwh6MHzS9iud627rHMhm9Q9Lfx/Utiydi3tRpbNVB0vWVu
D6d/b3ZddzGj4LqmAA7StTvdgU/lg6FU79rVxrqdYWp/VypPM3WLja+4ukaFYuZj
C2ndyFp7JhgdiO4kUIOznHjYHnGD2kLG9w6bnD85M7SrKFirTAO6TLg0Rpo9clDt
Oe/SXjDaKgjN50OFvZyklmS/FdCz3iI+uuYW713kTNWCQ4H31N8W0dRoR2k4RLZC
3GMbKYHuK9P8jDBMUGW7iwqkcnCHdEhmRa6oScjIBScsywUzl2ruUH5w2WvZ1O68
5BXXMyq9Zk9wuESTW0IvwnFv2PXBjp/uOSSH0Y+wIMElhJvcSuU3zgcSvgdot3LG
+rIRm25uScMCScDi6VR3kS7VIP7UdUm0nFeJhGWQ8vFh6Xpg7L+KQnRLEu+cTUj1
rcdeJP0uBE06flu7EuplgxwAtL8W59jccLI09UI91x6CAHKPcFyXhY2GtivUo2BN
oDl0uqSmR07gCKgxSmD0JLRmE/QyjPZxYABRyKGVtTBAvgLlP0L3TBy7L94Bi1LO
tsCYyv6xtYC67OZULZZ+uiQLdnn2mZdV4bMHwZVYytwfHvfdfi6s/w1yR3bZFC3j
UowYqKXZO2HDREpILRSD
=5itD
-END PGP SIGNATURE-

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

Re: [Tagging] Additions to public_transport scheme

[Michael Reichert]

Hi,

Am 07.07.2016 um 08:19 schrieb Colin Smale:
> You could use "long_name" to provide a version of the name which
> includes the discriminators 

In Germany there are ref_name=* and uic_name=* in use. (We have the same
problem)

Best regards

Michael




-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] steps parallel to escalator

[Michael Reichert]

Hi Bjoern,

Am 01.07.2016 um 19:30 schrieb Bjoern Hassler:
> A few questions about steps/escalators:
> 
> (1) Should an escalator always have "highway=steps"? I.e.
> highway=steps
> conveying=yes
> (see http://wiki.openstreetmap.org/wiki/Key:conveying ).

Yes. An escalator can be used as a steps even if it is defect.
highway=steps is a well known tag while highway=escalator is both
deprecated/out of date and not well known and therefore not supported by
much data users.

> (2) How would I tag steps that run in parallel to an escalator? Can this be
> done with one way only? If so how? Or would I need two ways? In my opinion
> it would be best to do it with one way, if they really are part of the same
> construction.

Yes, you draw to parallel ways. One way gets conveying=yes, the other
one not (or conveying=no).

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Subject: Feature Proposal - RFC - highway=social_path

[Michael Reichert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Alan,

Am 25.03.2016 um 23:54 schrieb Alan McConchie:
> I’d like to solicit comments on the following proposal, to create a
> new tag called "highway=social_path"
> 
> Wiki page is here:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Social_path

I vehemently oppose introducing this tag for the reasons given by
Tekim, Gdt and Stevea at the Talk page of your proposal.
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Social_path

It replaces a very old, very often used value by another new one and
its only intend seems to hide features from renderers/data users who
have not added support for your tag.

OSM maps what's on the ground. If there is a path, it is mapped as
path. If there is a sign/information board which prohibites using
unmarked trails, people add access=no to "unofficial" pathes.

> Note: As an experiment, we tagged 17 features in Marin County,
> California, as highway=social_path, but these have subsequently
> been re-tagged as highway=path, access=no. To my knowledge there
> are now no currently-existing examples of highway=social_path in
> the main database. See the discussion on the talk-us list for more
> information. Thread begins here:
> https://lists.openstreetmap.org/pipermail/talk-us/2016-March/016031.ht
ml

Some
> 
people would call this just vandalism.

There is already a discussion about this tag at German forum.
Proposals usually get discussed there when voting starts. Usually
people who hang out there only get notified if the proposal is bad.
Your proposal has been mentioned there today.
http://forum.openstreetmap.org/viewtopic.php?id=54139

Best regards

Michael


- -- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.
(Mailinglisten ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJW9oMAAAoJEB87G9rMCMyIrdwP/3dMkTmGrkjMkxn2g2pWfv5U
gtE9spMqHgKh5qL7FrjyQ+wDZ7ZrjUji1Gl6qID12sOYTRJgGyIMox+aJzm3SGlD
USThM11VHCfQG0EA8qX/sj4wUeqMD1YoNm+snIxEJzGgqm4MX3mtEY/5y4LYFaK8
ymAL40DLNoCVzpbCSCEW2rhEBBhG//sg3yjVbQZu2lmLcLxvQluNaI/XamnagZtp
HQcWzfmrD1Af4ifcWMGQ53cc9JzPJEnzJZBC+jN4aZiJiAR8lNQ0FKYtketiT9Ad
4KmYrDrZUBzufo0KIX7xVcCzQtQ9IvaybtqveSuDsn4hQA5KPDNG0ykwlet80iqb
2S36xiE4v5k6zpGvHtwIN/91mQ4/9241q9BrxcFaiC4j38lepehV1oj2pFetwHh5
Q7qmCRUDE/AHuBDtOddEh0owbXiHAPr+QHVpT7UY/wwrPwmzK9CggfGm9Qd8J4FM
Q/YwD/fAA/WcYrBc9rs5/SvwKkH1wG9MG06RurC6t+pGsp/Y0Dfn0g93uLoM+NBS
w5HE7JiEZTZ+36H+YXGCL0q5823CYxxdNl+dMXJZ+zYwJjbLorbHXmnYrNxuJ1IM
4y8qo8x6FlFmiE2FSW5hhmWAoIxlmuM+iY1xb7ZcmZ3428phxxCdxBCFhsfWMEbx
b0x6kEnWrGeSvXOCzEUJ
=YZIO
-END PGP SIGNATURE-

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

Re: [Tagging] importance=* tag (for transportation etc)

[Michael Reichert]

Hi John,

Am 18.03.2016 um 22:36 schrieb John Willis:
> I was told point-blank by the head of OSM-carto on github That (as I remember 
> it) 
> 
> https://github.com/gravitystorm/openstreetmap-carto/issues/323
> 
> A) "importance" is unverifiable, so it is useless for OSM. 
> 
> Gravitystorm:
> "Importance' and related concepts fails the absolutely vital verifiability 
> test, so it's not a suitable concept for OSM."

I agree that an importance tag for mountains is not a suitable concept
but a importance tag for train stations (or airports) is surveyable and
suitable for OSM. Just take the timetable or go out and stay one day on
the platforms, count and note down all stopping trains. In addition,
more important stations often have better/more facilities for
passengerts like a ticket shop (smaller ones only have vending
machines), a toilet, backeries, fast food stores, waiting rooms, etc.

If OSM would free of any importance-like tags, we would not have the
highway=* tag as we have it now. Tagging is highway=primary vs.
secondary, secondary vs. tertiary, tertiary vs. unclassified is often a
question of importance, not only width, paving and lane count.

Best regards

Michael


--
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] importance=* tag (for transportation etc)

[Michael Reichert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Am 18.03.2016 um 18:38 schrieb Daniel Koć:
> and it would be good to have universal scheme instead of 
> railway:station_category=* or flights_range=*. Looks like it is
> being already used and quite popular:

You know that you usually have more train stations than airports per
square kilometre, don't you? :-) That's why creating on tagging scheme
for both might be difficult.

> http://taginfo.openstreetmap.org/keys/importance

importance=* is mainly used in France. Usage in Germany was brought to
Germany by French mappers who mapped international TGV route
relations. It is only (with some few exceptions) used on railway
tracks, but not on stations.

http://overpass-turbo.eu/s/f6Q

> What do you think about making this scheme official?

Have you read the objections at OpenRailwayMap mailing list? Especially:
http://lists.openrailwaymap.org/archives/openrailwaymap/2016-March/00041
0.html
http://lists.openrailwaymap.org/archives/openrailwaymap/2016-March/00042
4.html
http://lists.openrailwaymap.org/archives/openrailwaymap/2016-March/00042
6.html

The old importance proposal might fit well for small countries like
Belgium, the Netherland, Austria or Switzerland. But it is not
suitable for larg countries (Germany, US) and islands (UK). How much
stations in UK or US have international trains?

Best regards

Michael


- -- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJW7HtDAAoJEB87G9rMCMyIq2wP/Al8isI462dSGjKrdEDIuA55
g7NZRxol329TiAX9+dAXhXD+s1Ill2BSE+ZcHoeNARf09gGYcXYKuG769iZY72ls
1IaG3lDYlVGYbTczpbFb0RI4uMR1zzZJPZwmrER/lh+VDD2OgAs2jnzXysFDWvNF
rHx9Uq7Pjbqd6PBX6PJxI2Tgm416o7YmnrDsxtBuXaJ0fJW2Adol7TmzahuCUN56
pDnpbRw5Qq38BKN5LHVjIsEbWn+OJA69r9u4UXYr0khlBffUuX00kyZgNL4sjMEi
By4SsAQ1DbBMmuQSjZQpICOu5O43KztTEGN40dEjgIjV5NGUnfuX6k3EHwyOqHV7
vxn4PWmzh0ZhQNFDMUHqeWpUqBVlR23S/fSHqO5Elu4ltDNk1sQ5FZdcXxjHrt27
rLn5rmtBng6XfBEPSwWZyAxry3I63xbaq6GmiBRc2Qm8KMvAQ2wjXRVyWjb5vQLa
6WjDWDAyyoC0WoXBBaEZb2LYA/+8OTzN7buGKFGVt4WIo+zNITeFSMG8vOnsvKKO
siSJKTW0OustBKYbVPuznPzt6x+sc4gi0mfKBmYfnDnzmxIXWQsxfkmZMhd1YjO4
3abhrMaygo/q+C8kPyKZuOrInROudN1r0SdghUeozQCCggcSt1rROTX+a+i2yCQk
ypcFgS9iNw9f+b+4Sl63
=d/T7
-END PGP SIGNATURE-

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

Re: [Tagging] Draft of proposal tag 'sells' for shops..

[Michael Reichert]

Hi,

Am 07.03.2016 um 08:56 schrieb Frederik Ramm:
> It is possible that some supermarkets would make their list of products
> available electronically and thus provide an incentive for a clever
> hacker to simply convert that to OSM. Once we say we accept a list of
> products for a supermarket, few would make the distinction of "surveyed
> list = ok, imported list = not ok"...
> 
> Such an automatic import would practically be the only way to keep a
> list of products current.
> 
> […]
> 
> Thankfully, this is hypothetical because we won't do it. OSM is a geo
> database and not a sales directory.

I agree with Frederik.

If shop chains like Lidl wanted to provide their list of products in an
automatically readable file format, they would provide an API url per
shop. This API url might be the only part of a product list I would
accept at OSM.

Example:

shop = supermarket
name = Lidl
opening_hours = Mo-Sa 08:00-21:00; PH off
addr:city = Karlsruhe
addr:street = Europaplatz
product_list_url = http://www.lidl.com/api/products/karlsruhe/europaplatz

App developers can use this url to create the link between OSM and Lidl API.

If the comapaies don't want to publish it, such data should be collected
as part of an additional crowdsourcing project. Linking between OSM
object and this OpenProductsDB could be done using postal addresses,
coordinates or shop numbers (sometimes printed on bills).

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)




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

Re: [Tagging] Road Running Railways

[Michael Reichert]

Hi Dominic,


Am 26. November 2015 13:49:33 MEZ, schrieb Dominic Coletti 
:
> I have noticed that there is no set tag for rails that are embedded
> within
> the road. One strategy I have had is to tag the road as highway=* and
> add
> another line with railway=rail. I just wanted to reach out to the
> community
> and see if there is another way.

Do you know embedded=*? Values:
yes, pavement, metal, wood, plastic

See OpenRailwayMap/Tagging at OSM wiki for more details.

Best regards

Michael


PS Did you know that you have posted business secrets to this public mailing 
list? ;-)
-- 
Diese Nachricht wurde auf einem Smartphone verfasst, ist daher nicht 
GPG-signiert und enthält Tippfejler.
This message was been written on a smartphone. That's why it is not GPG-signed 
and may contain tyops.

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

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Michael Reichert]

Hi,

Am 2015-11-06 um 11:24 schrieb Paul Johnson:
> […]
> *The fix: * I propose a goal of December 31, 2016 to eliminate ref=* as a
> method to describe an overlying route; this should be more than ample time
> for existing data consumers to catch up on doing a move and ensure data
> consistency for routes.  Kill the dinosaur:
> 
>- Deprecate ref=* on ways from having anything to do with the routes
>they run over, use relations instead and phase out the use of
>route-describing refs on ways (be it removal of the tag or replacement of
>the key's value with a ref that actually applies to the way instead of the
>route).

I strongly oppose this.

Usings relations for something which can be expressed using tags on ways
is usually a bad idea.

(1) Data users have to parse relations (i.e. need more processing time
and memory). Currently you only have to import ways (and nodes are used
to build the geometry if you convert OSM data into OGC simple features)
into your data structure (e.g. a PostGIS database) if you want to get
all road segments of German motorway "A 1". You just have to query the
ref column (maybe use LIKE opeator or something similar because A 1 and
A 61 share some road segments).

(2) Mappers have to work with relations. This makes editing OSM data
more difficult. We shold keep editing easy and the entrance hurdle as
low as possible. Mappers (and developers, too) are the most important
and most valueable resource at OSM.

(3) Relations break easily. We already have enough work to get all those
multipolygons repaired which are broken by newbies (and experienced)
mappers not to mention all those public transport relations which have
been broken sometimes for months or years.

>- Stop rendering this key and instead render the relations in opencarto
>and other featured layers.

Which key is rendered and which not, is decided by those people spending
days and weeks of time into OSM Carto. They usually decide which tags
they render and which not by looking which tags are in use and which not.

I think that we will still use ref=* over route relations at OSM in the
next two years.

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)




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

Re: [Tagging] More human readable values for traffic signs

[Michael Reichert]

Hi Mateusz,

Am Mon, 26 Oct 2015 08:58:08 +0100 schrieb Mateusz Konieczny:
> I recently started tagging traffic signs and I am surprised by wide
> usage country-specific traffic sign codes.
> 
> I think that at least common signs may be tagged by human-readable
> values. Some (see
> http://wiki.openstreetmap.org/wiki/Key:traffic_sign#Human-
readable_values
> ) are already used
> 
> I propose to add more like 
> - traffic_sign=oneway 
> - traffic_sign=no_stopping
> - traffic_sign=no_parking

At least the oneway sign looks different from country to country. Or do 
you expect that a French oneway sign looks like the German one? (The 
German one contains the word "Einbahnstraße", the German translation of 
oneway) https://commons.wikimedia.org/wiki/File:Zeichen_220-20.svg

And even traffic signs without text often look different because 
different countries use different fonts.

That's why I suggest to use the country prefixes followed by a number or 
the name depending if the country numbers its traffic signs (like 
Germany) or not (like Austria).

Best regards

Michael


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

Re: [Tagging] Unmarked opening hours

[Michael Reichert]

Hi Michał,

Am 2015-10-10 um 21:28 schrieb Michał Brzozowski:
> In the course of surveys, I fill in opening_hours of shops and other
> venues. Sometimes though, they are not marked outside. Therefore, when
> looking at a feature that lacks opening_hours other mappers and I
> can't tell the reason. I've been thinking of a standardized way of
> marking such cases, like:
> opening_hours:status=unmarked
> which is to be understood that mapper didn't see opening hours
> displayed outside (but other sources may be available).

I have been using opening_hours=none for this purpose.

If the community agrees on my suggestion, we have to fix all those
validators which show warnings on opening_hours=none.

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Rail maxspeed conversions

[Michael Reichert]

Hi Dave,

Am 2015-09-05 um 11:21 schrieb Dave F.:
> Update: The user has informed me there was a discussion & the outcome
> was to convert all to kph. Does anyone have a link to it?

Converting UK railway maxspeeds to kph is just mapping for the renderer.
OpenRailwayMap does not support mph speeds at the moment. But we
(developers of OpenRailwayMap) are going to support mph speeds in the
next months.

I suggest to revert these changes because the signs show mph speeds, not
kph speeds.

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Rail maxspeed conversions

[Michael Reichert]

Hi Dave,

Am 2015-09-05 um 12:58 schrieb Dave F.:
> Do you know where the UK maxspeed figures would have originally come
> from? I assume it's some form of open source database rather than
> someone foolishly walking the tracks.

There are multiple ways to get railway maxspeed data

(1) data with a compatible license
(2) mapping maxspeed signs along the railway line either by
walking/cycling along the line or by GPS/photo/video mapping by train
(3) GPS logging at a train and assuming the train /always/ drives at the
maximum permitted speed – a bad assumption because sometimes trains
drive slower because they are not delayed, try to save energy or try
have a slower freight or local train ahead of them.

I do not know if there is a public available dataset with UK maxspeeds
which has a compatible license. I suggest you to join OpenRailwayMap IRC
this evening (UTC) and ask if someone knows a dataset like (1).

irc.oftc.net
#OpenRailwayMap

In Germany we are only allowed to use (2) and (3).

Best regards

Michael aka Nakaner


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] highway=footway - Advanced definition: Distinction footway vs path

[Michael Reichert]

Hi Richard,

Am 2015-08-04 um 16:59 schrieb Richard:
 On Sun, Aug 02, 2015 at 11:43:21PM +0200, Michael Reichert wrote:
 I fully oppose highway=footpath. This is not backward-compatible and
 will therefore break almost all applications which use OSM data. It
 conflicts with existing, heavily used tagging. 
 
 quite the opposite. It won't break anything. It will be ignored for some
 time untill data consumers learn about th new tag.

Every data user who does not support highway=footpath will loose all
paths have highway=footpath because he expect them as highway=footway or
highway=path. That's what I call backward-incompatible.

Every data user has to add highway=footpath to his style sheets,
scripts, config files etc. Please read paragraph 8 to 10 of Andy Allan's
posting at Github 1 1/2 years ago.
https://github.com/gravitystorm/openstreetmap-carto/issues/230#issuecomment-29238913


Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] *** GMX Spamverdacht *** Re: highway=footway - Advanced definition: Distinction footway vs path

[Michael Reichert]

Hi Richard,

Am 2015-08-02 um 23:25 schrieb Richard:
 Rationale:

 The current definition (minor pathways which are used mainly or exclusively
 by pedestrians) is not specific in providing definite distinctive features
 between footway and path. The consequences are misconceptions and globally
 inconsistent assumptions in selecting the right type. 
 
 Another rationale: there is a mess and we need a fresh start with strictly
 defined set of properties which will not be changed again without vote as 
 happened with highway=path.
 
 Enhancing highway=footway won't help much as you can not change preexisting
 use by a new proposal.

I fully oppose highway=footpath. This is not backward-compatible and
will therefore break almost all applications which use OSM data. It
conflicts with existing, heavily used tagging. Why don't you just say:

highway=path and highway=footway area equal tags. You can freely choose.
You need additional (to be defined) for a more detailed specification.

Best regards

Michael



Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

[Tagging] Wiki: Key:level: proposed rewrite

[Michael Reichert]

Hi,

Am 2015-05-25 um 01:41 schrieb pmailkeey .:
 Any objection if I 'rewrite http://wiki.openstreetmap.org/wiki/Key:level ?
 
 It seems to have been written with the misconception that floor names are
 numbers when they're not.
 
 A rewrite:
 
- Won't affect existing names that appear as numbers.
- Will encourage mappers to use correct names for floors (as found in
the building) rather than attempt to convert them to meaningless numbers.

I oppose. Numeric level values can be used to display a building plan
layer by layer where higher floors lay over lower floors. Most software
which uses level=* at the moment expects that it is a numeric value.

Example: https://youtu.be/qcB5CP-IkLg?t=17m12s

If a building has named levels, you can still use numbers at OSM. (It's
like our usage of layer=*)

If you want that data users get the floor names, why don't you add a
level:name=* tag, e.g.
level:name=ground floor level=0
level:name=basement level=-1
level:name=underground parking level=-2
level:name=restaurant floor level=1?

Please do not try to change the meaning of a frequently used tag.

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] RFC - obligatory usage - bicycle=obligatory

[Michael Reichert]

Am 2015-03-28 um 00:54 schrieb Mateusz Konieczny:
 Adding new value to a bicycle tag is a terrible idea. There is a widespread
 support for bicycle=designated
 and retagging cycleways to bicycle=obligatory would result in a breaking
 data.
 
 Note also existence of bicycle=use_sidepath that is solving this problem
 without breaking data.
 
 New key, something like bicycle:obligatory=yes would be acceptable.

+1


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Proposal : Move smoking tag to active status

[Michael Reichert]

Hi Bryce,

Am 2015-03-21 um 01:54 schrieb Bryce Nesbitt:
 Any objection to moving:
 http://wiki.openstreetmap.org/wiki/Proposed_features/Smoking
 because it is heavily used and obviously well established.

I agree. Because it is used on 47541 objects at OSM all over the world,
it's best to move the page to Key:smoking.

We do not have to vote on every peanut. OSM wiki should document how
tags are used and not how tags must be used.

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Proposal : Move smoking tag to active status

[Michael Reichert]

Hi,

Am 2015-03-21 um 02:29 schrieb Bryce Nesbitt:
 Additions to that page, I'd think, should be proposed separately.
 
 -
 The utility undergrounding RFC proposes tagging for a similar regional
 default value.
 http://wiki.openstreetmap.org/wiki/Proposed_features/Quickly_Marking_Utility_Wires
 Eventually the tools will catch up :-)
 
 But that case is simpler.  Smoking rules depend on the area AND the
 establishment type:
   smoking_default:yes=restaurant;cafe
   smoking_default:unknown=bar
 And the legal definition of the restriction may not mach OSM's definition
 (e.g. smoking
 maybe allowed in certain bars owned by people who donate money to a
 particular party ;-).

There are several reasons why I do not like tagging smoking rules on
boundary relations.

(1) It is difficult to map smoking restrictions in
restaurants/bars/cafes to OSM tags. By default, smoking in all German
states is prohibited but there are exceptions. Let's have a look at the
exceptions in the State of Baden-Württemberg (south-west Germany):

1. Smoking is banned in all restaurants, pubs, cafes, discothèques.
2. Smoking is allowed at pubs if they are smaller than 75 m², do not
serve hot meals and must not be entered by people below the age of 18 years.
3. Smoking is allowed at separated rooms at discothèques if these
separated smoking rooms do not have a dance floor and the whole
discothèques must not be entered by people below the age of 18 years.

How would you now tag the boundary relation of Baden-Württemberg? Please
note that a small pub (60 m²) does not have to allow smoking, i.e. you
cannot tag defaults which are valid for all pubs. It is better not tag
any default values in such states and to wait until a mapper visits the
restaurant/pub and add the tags.


(2) Such bans on smoking often extend on other locations, e.g. stations
[1], public transport vehicles, public buildings, … How many tags do you
want to add to boundary relations.


(3) Boundary relations easily and often break, i.e. smoking rule data at
OSM can often not be used if the boundary of a city/state/country is broken.


(4) OSM data should be easily to use. Why should we force our data users
to use boundaries if they just want to create a OpenCigaretteMap?


(5) OSM data should be easy to contribute. Please keep the
on-the-ground-rule in mind.


Best regards

Michael
(not and never smoking)



[1] How to handle small areas on platforms where smoking is allowed?
https://commons.wikimedia.org/wiki/File:Raucherbereich_im_D%C3%BCsseldorfer_Hauptbahnhof_DSCF1367.jpg
(you can find these yellow marked smoking areas at all major German
stations above ground.

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Blatant tagging for the renderer: bridges abandoned railways

[Michael Reichert]

Hi ael,

Am 2015-03-09 um 15:22 schrieb ael:
 I have resorted to changing railway=abandoned to railway=disused
 on several occasions just to get mapnik and friends to render 
 bridges. Bridges over roads and rivers are major features of relevance
 to tall vehicles and boats, so really should show up on standard
 rendering.
 
 According to the wiki railway=abandoned applies when the rails have been
 removed, and disused should be used when the rails are still present.
 
 Not suprisingly this has been raised before, as for instance at
 http://wiki.openstreetmap.org/wiki/Talk:Railways.
 
 I don't like tagging for the renderer and normally avoid it, but in this
 case it seems to be necessary to maintain the reputation of OSM/mapnik.

Would you please change this back?! There also other maps using OSM data
which rely on good and exact tagging!
http://openrailwaymap.org

There is no reason to increase the reputation of OSM-Carto. If it
renders bad images, they bad and the stylesheet has to be fixed, not the
data!

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Blatant tagging for the renderer: bridges abandoned railways

[Michael Reichert]

Hi,

Am 2015-03-09 um 16:06 schrieb ael:
 Well, I have only changed the tag on the bridges themselves, and only on
 ways for which I did the original (and usually any subsequent) survey
 and edits. So I am not corrupting other people's data.

Wrong! You have corrupted data because you have changed tags to values
which are wrong. What about people who want to calculate the length of
the railway network including disused tracks which have not been removed
yet (and therefore are easy to reactivate)?

The edits you did can be described as (semi-)vandalism.

 Nevertheless, I agree that it is a problem with OSM-Carto, as I
 indicated in the OP.
 
 I have just been asked to give a talk about OSM to a local group
 including Councillors who are impressed with OSM and considering 
 using it for Council purposes. There are many historical abandoned
 railways in the area (related to mining) and I think that they will be
 singularly unimpressed if prominent major bridges on the local lanes
 are missing. I suppose that it might be a useful lessson in
 distinguishing the data base from the rendering, but there might be
 sceptics present. Also I want to keep it simple at least for the first
 introduction. 

Well, if these people do not like OSM because /one/ OSM-based map does
not show a couple of bridges, it is not bad if they do not use OSM. OSM
is a database and no map! Please explain this if they ask why osm.org
does not show bridge X.

 So is there a bug tracker that I have missed for the stylesheet?

https://github.com/gravitystorm/openstreetmap-carto/issues

btw, what's your nickname?

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Tram tracks running in a road

[Michael Reichert]

Hi Luca,

Am 2015-02-06 um 17:29 schrieb Luca Sigfrido Percich:
 first time I write to the list (after lurking for a while), so I introduce
 myself. I am from Milano - Italy, I work for the municipality's agency for
 environment and mobility, and we'we been working for the last months to
 integrate our road graph with OSM.
 
 Currently in Milano all tram tracks are mapped separately, so they are all
 oneway and no way has both highway=* and railway=tram tags (apart from some
 cases we're correcting).

Thats right. Tram tracks and the street ways should be to different ways
(may share the nodes in some cases) because we have a couple of tags in
OSM which are used for railway and road infrastructure (e.g. maxspeed=*).

Here some examples how to map if

(1) tram tracks totally separated from car traffic:
http://www.mapillary.com/map/im/ZCD0rR9FfLzIc-SsNFTStg
https://www.openstreetmap.org/#map=19/49.00687/8.42918

(2) tram tracks share space with cars, only a white line between the two
directions
http://www.mapillary.com/map/im/yP5nkfgRBjWWklXJHRwHUA
https://www.openstreetmap.org/#map=19/48.77655/9.19175

(3) tram tracks share space with cars and there is only one tram track
which is located in the middle of the street
https://www.openstreetmap.org/#map=19/48.36955/10.90007
http://www.mapillary.com/map/im/p2Ka3oF2zQtXxBvQoVmvNA

 Now, we would like to store the information wether a certain rTailway track
 runs in a road sharing the same space with motor vehicles.

You do not need to change current tram mapping [1] to do this. Take a
GIS of your choice, import OSM data, calculate buffers around tram
tracks and street ways and intersect them. Tram track buffer should be a
little bit wider than the used structure gauge [2]. Ask your local tram
operating company which structure gauge is used on which tram line (it
may differ between older and newer lines) if it is not mapped yet
(structure_gauge=* or loading_gauge=* [5]).

Calculating buffers around streets is a little bit more difficult. You
have to check how wide the street is. Check following tags to do this:
- oneway=* (i.e. one OSM ways per driving direction or one way for both
  directions),
- number of lanes (lanes=*)
- mapping offset (placement=*, see [3] and [4])
- width=* (you can measure width=* from aerial images)
- if lanes=* and width=* is not tagged, you can estimate the width by
  road classification (highway=primary is often wider than
  highway=tertiary) or add map it yourself

If you want to improve OSM you can add landuse=railway where tram does
not share the space with cars and use landuse=railway areas in your
buffer calculation/intersecting

 I am referring to situations similar to this one:
 
 http://wiki.openstreetmap.org/wiki/File:Tram_Amadeo.jpg
 
 Which is here on the map:
 
 https://www.openstreetmap.org/#map=19/45.470987/9.236118
 
 I searched the wiki for a tagging or relation scheme, but found none.
 
 I was thinking about a simple tagging scheme: tram=yes|forward|backward for
 the highway, and road=yes for the railway.

There is one disadvantage. If I (or someone else) edit the tram tracks
there (e.g. because the have been removed or separated from car lanes),
I won't look at the neighbouring street way because trams tracks already
have been mapped separately. Don't map things which can be derived by
spatial queries (see above).

 From the previous example (the picture points at the opposite direction of
 the highway on which it was taken:
 
 For the center way (road):
 
 tram=yes (it's on both directions)

A mapper who has not read this discussion maybe think that tram=yes is
an access tag (in some countries, e.g. Germany, trams have to observe
(car) traffic signs because trams are considered as normal street
traffic by law) and remove it because it is not necessary (see the
access tagging hierarchy at OSM wiki).

 and on the two railways:
 road=yes (the track lies on a road used by motor vehicles)
 
 We could also user a lanes modifier:
 lanes=3
 lanes:backward=2
 tram:lanes:backward=yes|no
 tram:forward=yes

Tagging this can be useful if someone wants to render a lane diagram.
Maybe you can use these tags in your GIS, too.

 The tram tag should not be used for tracks which run separated from the
 road (they are tagged with railway=tram).
 
 The tram tag should go along with access tags, as we have lanes reserved
 for trams and buses/taxis:
 
 http://wiki.openstreetmap.org/wiki/File:Tram_xxii_marzo.jpg
 
 So the center way (carriageway reserved to psv with two tram tracks in
 shared space) would get tagged as:
 access=no
 bus=yes
 taxi=yes
 tram=yes
 
 We could also think about a relation, type=tram_on_road, it could be useful
 for sorting things out in complex multi-carriageway situations like this
 one:
 
 https://www.openstreetmap.org/#map=19/45.49833/9.19607
 
 but would also be more difficult for users to mantain and for clients to
 consume.

Maintaining is the main problem of street relations. A mapper who edits
this area 

Re: [Tagging] Deprecation of associatedStreet-relations

[Michael Reichert]

Hi,


Am 22. Januar 2015 11:45:47 MEZ, schrieb althio althio althio.fo...@gmail.com:
  Please vote here:
  https://wiki.openstreetmap.org/wiki/Talk:Relation:associatedStreet
 
 Is this a formal voting?

It is not as formal as a proposal voting. I would like to know how the 
community (those who vote) think about associatedStreet relations. I think that 
in Germany the majority does not like them (anymore).

 Is there a date for start and end vote?

No, there is no end date at the moment. Start date was yesterday. I will 
announce a end date. This end date will be date of announcement of end of 
voting + 14 days.

 It looks strange, hidden on a Talk:page without the usual template or
 RFC or call for votes on the international mailing lists.

German forum and talk-de have been notified by myself. You may notify your 
local community if it will not read the next issue(s) of weeklyOSM.

Best regards

Michael
-- 
Diese Nachricht wurde auf einem Smartphone verfasst, ist daher nicht 
GPG-signiert und enthält Tippfejler.
This message was been written on a smartphone. That's why it is not GPG-signed 
and may contain tyops.

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

Re: [Tagging] Feature Proposal - RFC - (Traffic Signals)

[Michael Reichert]

Hi,

Am 2015-01-18 um 19:02 schrieb fly:
 Additional to below I want to mention that on a micromapping style a
 traffic_signal is placed one the pedistrian crossing or the stop_line. I
 even came across ones one the stop_line and an addition highway=crossing
 on the pedestrian crossing.
 
 I am tagging direction=* for the direcion it faces.
 
 Together with the :lanes tagging you do not need any relation at all but
 could simply add the information on the node with :lanes tagging

I agree you. I have described a way to map it without relations using
lane tagging which should exist if you want to have useful traffic
simulations.

https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Traffic_Signals#This_tagging_scheme_is_the_total_opposite_of_KISS

I mentioned this proposal at German OSM forum.
http://forum.openstreetmap.org/viewtopic.php?id=29712

Main comments there:
A large number of traffic lights/crossings have no programm. The show
green to the branch streets if a waits there. Otherwise they show red to
the branch streets and green to the main street. There are also traffic
lights in cities which
- show green for a couple of minutes if fire brigades approach to
  clean the way.
- can have extra-extra programms if a special event changes traffic flow
- have multiple programms (one on the morning rush hour, one for the
  low-traffic periode between 9 and 12 a.m., one afternoon programm,
  one evening rush hour programm, one late-evening programm and a
  Sunday programm)

Best regards

Michael


-- 
I prefer GPG-encrypted emails.



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

Re: [Tagging] Adding values to usage=* key for power transmission

[Michael Reichert]

Hi,

Am 2014-11-23 um 23:09 schrieb François Lacombe:
 As suggested on Talk page of Power transmission refinement proposal, power
 lines and cable should be described with a key giving their usage in the
 network.
 https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Power_transmission_refinement#line.3D.2A_and_cable.3D.2A:_similarity_and_difference
 
 I knew usage=* and it can be the ideal key to indicate usage=transmission,
 usage=distribution,... on power lines or power cables.
 But it is currently and exclusively used for railway tagging.
 https://wiki.openstreetmap.org/wiki/Key:usage
 
 Is it acceptable to extend its definition to power lines or another key
 should be used?
 https://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement#overhead_power.3Dline

I am one of the active railway mappers in Germany and work (togehter
with other mappers) on railway tagging. The following is my personal
opinion.

I think that there is no problem do use a key like usage=* for two kind
of objects. There are already some keys in use which spread over several
object classes, e.g. service=*, maxspeed=*, operator=* or
wheelchair=*. It is used for highway=service to give information which
type of service street it is. If service=* is tagged on a ways with
railway=rail/light_rail/…, it describes that this track is *not* an
important track. Only siding, yard and crossover tracks get service=*.
Tracks of a long railway line running through a station do not get
service=*, they are tagged with usage=*.
service=* is also used for waterways.
https://wiki.openstreetmap.org/wiki/Key:service

I do not know why anyone should tag one OSM way both with power=* and
railway=*. Catenary of a railway track is mapped by tagging
electrified=contact_line, voltage=* and frequency=* onto the railway
way. There are already some ambiguities with maxspeed=* one trams
running in street. These are solved by either mapping the street as two
ways (if a barrier is between) or mapping the tram tracks as two tracks
or (if a circular/one-track tram line) mapping two independent OSM ways
(as a precursor of a future tag set datatype).

Just have a look at banks. A bank can be tagged with atm=yes and
opening_hours=*. What's the solution? Just split the bank into a bank
node and an independent atm node (if atm is 24/7 accessible).

Because usage=* does not say what a OSM way represents, data users
always have to check if it is a railway track or a power line. If a way
has (by accident) only usage=* and neither power=* nor railway=*, this
should be fixed by a mapper looking into OSM object history.

I suggest you not to use network=*. In difference to usage=*, network=*
does not have a fixed set of values. network=* is used (among other
use-cases) for a human-readable name of a bus/tram/train/… network. I
think that mixing free and fixed values in one key is worse than using
usage=* for two categories. Maybe mappers start to map networks like
Main power network of XY power company in future. Then mappers would
best use network=* as public transport mappers do.

We should not start at OSM to add a prefix (as namespace) in front of
every tag. What about a mechanical edit changing wheelchair=yes to
restaurant:wheelchair=yes? :-)

Best regards

Michael



-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.



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

Re: [Tagging] Dispute with user over changing wiki page

[Michael Reichert]

Hi Martin,

Am 2014-11-13 um 17:56 schrieb Martin Koppenhoefer:
 I'd kindly ask you to not point to actual or presumed real life identities
 of OSM contributors and to not disclose their (presumed/actual) place of
 residence on public lists, unless they are publicly known or the mapper has
 authorized you to do so.

I agree you. The location of ulamm is already public. Have a look at his
changesets and all the wiki pages he edited and where he argues with
other users. You will find out that he has local knowledge in B.

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.



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

Re: [Tagging] Dispute with user over changing wiki page

[Michael Reichert]

Hi Pee Wee,

Am 2014-11-11 um 19:20 schrieb Pee Wee:
 Thanks Micheal
 
 I thought I just wait some days for other to reply but unfortunately no
 more then yours.  The question we still have is : What can we do? I suppose
 the DWG will only block when harm is done to the OSM database and not on
 any wiki pages. Anyone else for a recommendation as to what we can do?

I was asked by DWG for advice in the case of ulamm. At that time he was
reported the third or fourth time to DWG (the first report was about his
vandalism in Poland and reported by myself in June). At that time
(this was in September) there was nothing which would have justified a
block. But it was obvious that he was the problem. In almost all debates
between him and the community, he was alone with his opion, everyone
else disagreed with him.

DWG told him in their last official message cleary that he would be
blocked (indefinitely) if complains about him continue in order to save
peace inside community. They told him that it is not ok to modify
tagging documentation to use these modified wiki pages as evidence for
his arguments.

I, as adivsor, have got a copy of this official message on 4th October
2014. But it covers whole OSM – database, wiki etc.

My first message was sent to DWG in CC. I think they have a look at this
issue soon (Frederik has handled it the last time). Maybe I have to ask
him in a few days.

Best regards

Michael



-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.



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

Re: [Tagging] Dispute with user over changing wiki page

[Michael Reichert]

Hi PeeWee32,

Am 2014-11-08 um 16:47 schrieb Pee Wee:
 We are writing to you for advice on what steps we should or could take
 next. The situation is best summarized as:
 
 
 1. A user is attempting to change, without consensus, the meaning of a tag
 that was accepted through a proposal process. There are 2 changes that are
 arguable: one is a considerable change and another is a recommendation to
 add a redundant (but not wrong) tag;
 
 2. Several attempts have been made to revert the page to it's original
 state, without success;
 
 3. Several times we have advised him to go to the tagging mailing list to
 discuss these changes with more people, without success.

My guess after reading the first sentence of your mail was right. There
is no need to hide the name of this user. Its name is ulamm (Ulrich
Lamm) from Bremen. He has long history of conflicts with other mappers
in Bremen, Germany and Germany's eastern neighbours. Let me shortly
summarize his conflicts:

1. name:de
In June this year he tried to delete almost all name:de tags in areas
which belonged to Germany before World War II. He said that OSM is full
of nazis and only capitals of foreign countries should have German names
in OSM. He also deleted other name:*=* tags in Poland and Czech
Republic. His motivation was that name:de=* had a higher priority than
name=* or int_name=* in rendering at openstreetmap.org.
http://forum.openstreetmap.org/viewtopic.php?id=25719

2. Bicycle Tagging
This conflict exists especially in Bremen. I think you know the
important topics of this conflict.

In almost all topics his opinion is in difference to the opinion of OSM
community. He is a mapping-for-the-renderer-mapper and you cannot
discuss a topic with him.

Both in case 1 and 2 he was reported to DWG several times. DWG told him
that he will be blocked indefinitely if there is another conflict with
other OSM contributors. I would like to see himself blocked. It would
not be a loss for OSM community.

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.



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

Re: [Tagging] highway=speed_camera equivalent for non-speed enforcement types

[Michael Reichert]

Hi Ronnie,

On 22. Juli 2014 07:35:07 MESZ, Ronnie Soak chaoschaos0...@googlemail.com 
wrote:
 I've mapped some traffic light enforcement cameras lately and
 stumbled across the somehow missfitting tag highway=speed_camera.
 
 It was obvioisly invented for cameras enforcing only speed limits.
 
 Now the actual enforcement can be quite flexibly tagged by the
 enforcement
 relation and technically, the node used as 'device' role in the
 relation
 does not have to have tags of its own.
 But nodes without tags (and just relation membership) are prone to
 accidental deletion.

Why don't you just add anotd tag?

note=This traffic light enforcement camera mapped as relation. Only edit if you 
are an experienced mapper!

Best regards

Michael 
-- 
Diese Nachricht wurde auf einem Smartphone verfasst und enthält daher 
Tippfejler.

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

[Tagging] Native English speakers: locker or lockbox?

[Michael Reichert]

Hi,

over a year ago I was indoor-mapping the central train station of
Heilbronn, Germany and looked for a tag to tag a locker/lockbox like this:
http://commons.wikimedia.org/wiki/File:Schlie%C3%9Ff%C3%A4cher_-_Bahnhof_Neumarkt_Oberpfalz.jpg

After reading a discussion at talk-de from October 2010 [1], I decided
to tag them amenity=lockbox. [2] In that discussion they decided to use
the amenity key instead of tourism key.

At the moment Constantin Müller (aka ubahnverleih) and I think about a
consistent tagging of this amenities. At the moment there are 9 objects
tagged amenity=lockbox and 30 objects tagged amenity=locker [3, 4].
Because there is few difference between both tags I would like to ask
the native English speakers at this list to answer me following question:

What word describes a locker/lockbox at a train station (see linked
image above) better? Locker or lockbox? In the discussion at talk-de
Martin Koppenhöfer wrote that a lockbox can be found at a bank (for
money, gold etc.). But he was not sure. [5]

Best regards

Michael


[1] German:
https://lists.openstreetmap.org/pipermail/talk-de/2010-October/076965.html
[2] https://www.openstreetmap.org/way/215036986#map=18/49.14281/9.20764
[3] http://taginfo.openstreetmap.org/tags/amenity=locker#overview
[4] http://taginfo.openstreetmap.org/tags/amenity=lockbox#overview
[5] German:
https://lists.openstreetmap.org/pipermail/talk-de/2010-October/076976.html

-- 
I prefer GPG encrypted emails.



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

Re: [Tagging] Native English speakers: locker or lockbox?

[Michael Reichert]

Hi Richard,

Am 24.06.2014 19:41, schrieb Richard Mann:
 left luggage for the facility as a whole, probably locker for them
 individually
 
 it might be more international to call them lockers, though

Thank you for the additional phrases. Are your answers in British
English? (Because tags should be in British English, shouldn't they?)

 On Tue, Jun 24, 2014 at 6:32 PM, Michael Reichert naka...@gmx.net wrote:
 At the moment Constantin Müller (aka ubahnverleih) and I think about a
 consistent tagging of this amenities. At the moment there are 9 objects
 tagged amenity=lockbox and 30 objects tagged amenity=locker [3, 4].
 Because there is few difference between both tags I would like to ask
 the native English speakers at this list to answer me following question:

 What word describes a locker/lockbox at a train station (see linked
 image above) better? Locker or lockbox? In the discussion at talk-de
 Martin Koppenhöfer wrote that a lockbox can be found at a bank (for
 money, gold etc.). But he was not sure. [5]


Taginfos says:
9 amenity=lockbox
30 amenity=locker
48 amenity=lockers
4 amenity=left_luggage

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.



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