Re: [Tagging] How to tag a way with several conditional access restrictions

[SelfishSeahorse]

Hi Paul

This is not perfect, but it is how I would tag that service road:

vehicle = delivery
disabled = yes
foot = yes
description = "Vehicular access for launching boats only. Vehicles
must be returned to the main parking area."

Maybe someone else has a better idea.

Note that the wiki states that wheelchair=* should be used instead of
disabled=*. However, I think this is wrong: wheelchair=* gives
information whether something is suitable for wheelchair users, while
disabled=* gives information about its legal access.

Cheers

Markus

On Mon, 30 Jul 2018 at 15:53, Paul Burton  wrote:
>
> A local fishing lake has a parking area for all users, then a gravel
> service road that leads from the parking area to the lake shore. Signage
> on the service road indicates that the road is for use by:
>
> * Vehicular access for launching boats only (explicitly stating that the
> boat-carrying vehicle must be returned to the main parking area and the
> user(s) must walk back to the lake)
>
> * Vehicular access by disabled users (who are then presumably allowed to
> park their vehicles near the lake shore for the duration of their visit)
>
> * Pedestrian access for all other users
>
> The wiki goes into some detail about conditional access tag values, but
> given the specific nature of this situation, I'm unsure how to proceed.
> Any advice is welcome.
>
> --
> Paul Burton
> p...@paul-burton.com
> https://paul-burton.com/keys
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Put the name in sidewalks and cycleways

[SelfishSeahorse]

Hola

On Sun, 5 Aug 2018 at 18:44, yo paseopor  wrote:
> Why the road is the only item I don't have any doubt to tag it with name= ? 
> Why the road is more important than the sidewalk or the cycleway? What is 
> more important : person, car or bike?

Because a sidewalk is a part of a road (like a separate carriageway),
i think that it should also be tagged with the name of the road.

Saludos

Markus

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

Re: [Tagging] Put the name in sidewalks and cycleways

[SelfishSeahorse]

Hi Tobias

Yes, sidewalk mapped as ways are problematical for routeing. In order
to not create islands in (residential) areas without marked crossings,
one has to map unmarked crossings. If there are lowered kerbs or if a
sidewalk is just interrupted by a perpendicular street, it seems okay
to map unmarked crossings (see for example [^1]). But in absence of
lowered kerbs and if the sidewalk doesn't continue (for example here
[^2]), mapping an unmarked crossing or connecting the sidewalk with
the road differently just seems arbitrary.

[^1]: 
[^2]: 

However, sidewalks tagged as property on the road don't seem to be
unproblematical too, especially at intersections. For example, look at
this crossroads [^3]: how should a router know that a pedestrian has
to cross Engehaldenstrasse here [^4] when guiding her or him along
Schützenmattstrasse? Or how would you map a crossroads with multiple
carriageways (like here [^5]) with sidewalks only tagged as property
on the roads?

[^3]: 
[^4]: 

Perhaps, a solution would be to map a sidewalk and the road it belongs
to as areas (area:highway=*). That way, the sidewalk and the road were
connected and the connecting line could even be mapped with a kerb
way.

Regards

Markus

On Sun, 5 Aug 2018 at 17:44, Tobias Knerr  wrote:
>
> On 05.08.2018 17:16, yo paseopor wrote:
> > So what is the correct way to map it: with name? or without name?
>
> Adding name tags to separately mapped sidewalks is an attempt to fix
> just one of the symptoms of a deeper problem: The lack of a
> machine-readable link between the sidewalk way and the road it belongs to.
>
> This fundamental shortcoming of the current approach for
> sidewalk-as-a-way mapping also causes several other issues, though,
> which aren't as easily compensated for. There's nothing wrong with
> copying the name per se, but needing to do so is a red flag.
>
> So my recommendation is to stick with sidewalk tags. Alternatively,
> create a relation between each highway way and the one or two sidewalk
> ways belonging to it. (You'll probably balk at that, but something along
> those lines would be needed to actually _solve_ the inherent flaws of
> the sidewalk-as-a-way approach.)
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Slash, space, or spaced hyphen in multi-lingual names

[SelfishSeahorse]

On Fri, 10 Aug 2018 at 21:42, marc marc  wrote:
> In the same way as in osm we defined ";" as being the separator between
> several values of the same key (with several exceptions), it would be
> useful to define a separator between several lines of the same key.

Then why not also use the semicolon to separate multilingual names?
After all, two names are two values. Besides we already use the
semicolon for alt_name. [^1]

[^1]: https://wiki.openstreetmap.org/wiki/Key:name#Multiple_names

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

Re: [Tagging] Slash, space, or spaced hyphen in multi-lingual names

[SelfishSeahorse]

I suspect that the different punctuation marks on OSM are a
consequence of different writing habits in the respective regions,
which i recommend to follow.

For example, in English-speaking regions and in Switzerland the slash
without spaces is used (e.g. Biel/Bienne), unless one of the two names
already has a space, in which case the slash is usually set with
spaces (e.g. Bielersee / Lac de Bienne).

Regards
Markus

On Wed, 8 Aug 2018 at 14:21, Andy Mabbett  wrote:
>
> Please see:
>
>
> https://wiki.openstreetmap.org/wiki/Talk:Multilingual_names#Slash.2C_space.2C_or_spaced_hyphen.3F
>
> where I wrote:
>
> This page (and perhaps actual practice) is inconsistent in suggesting:
>
> * slashes: name=L'Alguer/Alghero (New Zealand, Portugal, Sardinia)
> * spaced hyphens: name=Rue du Marché aux Poulets - Kiekenmarkt (Belgium, 
> Spain)
> * spaces: name=干諾道中 Connaught Road Central (Hong Kong)
> * spaced slashes: name=Le Rhin / Rhein (shared boundaries)
>
> Greater consistency would surely be advantageous?
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk

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

Re: [Tagging] addr:street=* combined with place=square, name=*

[SelfishSeahorse]

Hi

I'd rather use addr:place="Square Name" in that case. In don't agree
that addr:place is 'intended for larger objects like "villages,
islands, territorial zones"'. I also use addr:place e.g. for
settlements (place=neighbourhood) or hamlets, if there is no street
with the addresses' name (example: [^1]).

[^1]: 


Regards
Markus
On Mon, 13 Aug 2018 at 21:05, Toggenburger Lukas
 wrote:
>
> Hi
>
> I'm the main author of the address view of Geofabrik's OSM inspector: 
> http://tools.geofabrik.de/osmi/?view=addresses , a QA tool for OSM, whose 
> sourcecode you can find at https://github.com/ltog/osmi-addresses/
>
> Some time ago I received the following issue and subsequent pull request:
>
> - https://github.com/ltog/osmi-addresses/issues/111
> - https://github.com/ltog/osmi-addresses/pull/115
>
> The submitter johsin18 proposes the following:
>
> Given a (node|way) with addr:street=theName and a (node|way) with 
> place=square, name=theName, the first object should logically be tied to the 
> second. Correspondingly, osmi-addresses should recognize this and not display 
> it as an error as it is currently the case, e.g. at: 
> http://tools.geofabrik.de/osmi/?view=addresses=7.59448=47.54290=18=buildings,buildings_with_addresses,postal_code,entrances_deprecated,entrances,no_addr_street,street_not_found,place_not_found,misformatted_housenumber,nodes_with_addresses_defined,nodes_with_addresses_interpolated,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads,nearest_areas,addrx_on_nonclosed_way
>
> osmi-addresses currently expects either
> addr:street=* used in combination with highway=*, name=*
> or
> addr:place=* used in combination with place=*, name=*
>
> Both myself and the current maintainer of osmi-addresses (=Nakaner) are 
> unsure if this proposed change would be appreciated by the larger public or 
> not. We are therefore seeking your opinion.
>
> Best regards
>
> Lukas
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

[Tagging] How to tag small canals?

[SelfishSeahorse]

Hello

What is the usual (or sensible) way to tag small canals like mill
races (example: [^1]) or small irrigation channels (example: [^2]),
i.e. the small equivalent of waterway=canal?

[^1]: 
https://commons.wikimedia.org/wiki/File:15-19-077,_mingus_creek_-_panoramio.jpg
[^2]: https://commons.wikimedia.org/wiki/File:2003-Suone.jpg

It seems to me that waterway=ditch +
usage=headrace/tailrace/irrigation fits best, but the wiki defines
waterway=ditch as 'a small man-made draining waterway, often found
along roads'.

Regards

Markus

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

Re: [Tagging] How to tag small canals?

[SelfishSeahorse]

On Thu, 16 Aug 2018 at 18:20, Christoph Hormann  wrote:
>
> On Thursday 16 August 2018, Martin Koppenhoefer wrote:
> >
> > The canal definition was changed in March 2018, before it said to use
> > canal only for „the largest waterways created for irrigation
> > purposes“
>
> Yes, that was the obvious attempt to expand the narrow scheme to other
> parts of the world in a superficial way oriented at the standard style
> rendering but not at the actual semantics.

Actually, it's only drain that doesn't seem to make sense
semantically, but ditch seems to be fine for smaller canals used for
drainage and irrigation, at least according to the definitions by
Wikipedia[^1] and the Cambridge Dictionary[^2].

[^1]: 
[^2]: 

I'm not sure if a (smaller) mill race can also be called a ditch, but
i think it makes sense to have at least two tags for man-made channels
of different width.

In my opinion the material of the lining/confine should better be
tagged separately, perhaps confine:material=concrete/wood/

As for natural waterways, I could imagine the following classification
based on width:

* waterway=stream/brook - possible to jump across (< 1 m wide?)
* waterway=creek - small to medium-sized natural stream (1-3 m wide)
* waterway=river (3-10 m wide)
* waterway=broad_river (> 10 m wide)

Of course we could just use width=*, but it's not always easily
possible to measure the width (e.g. in a forest) and sometimes it
changes often.

However, if new waterway=* values were introduced, it would be
necessary that OSM Carto would render them from the day they were
approved, otherwise people would not use them.

Cheers

Markus

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

Re: [Tagging] Slash, space, or spaced hyphen in multi-lingual names

[SelfishSeahorse]

Maybe a possible solution to get rid of name=* tags containing names
in multiple languages would be to add the information about which
languages are spoken in a particular region to its boundary relation
(e.g. spoken_languages=de;fr to the municipality boundary of
Biel/Bienne). However, the renderers would then have to take these
relations into account.

Cheers
Markus

On Thu, 9 Aug 2018 at 13:25, Marc Gemis  wrote:
>
> ]
> > > p.s. It is not the first time this question pops up.
> >
> > That can be a sign that something is amiss.
>
> the previous times it popped up was not for consistency reasons, but
> to do something on carto-css for osm.org
> We do have multiple local tile sets for Belgium, where we do not have
> that problem at all.
>
> As a Flemish person it's even annoying that software like OsmAnd
> announces the name field and not name:nl
> Nobody uses the composed FR-NL name in real live. You always use one
> of the two depending on preference or situation.
>
> As someone suggested before, perhaps we should get rid of the usage of
> name field for the default osm.org map and let the renderer decide
> what (and how) to display names in multi-language areas based on
> name:xx fields.
> Let the local community assist in setting up those rules for carto-css
> (e.g. French before Dutch), but the separator is decided by the map
> maker.
>
> All that seems better than starting to change the name (and
> addr:street) field of tens of thousands of objects just because
> someone does not like the rendering on the default osm.org map.
>
> m.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Slash, space, or spaced hyphen in multi-lingual names

[SelfishSeahorse]

On Wed, 8 Aug 2018 at 20:03, Daniel McCormick  wrote:
> I propose that only one language is used for the name= tag. This will help to 
> create a standard for naming that will bring clarity and consistency. If 
> multiple languages are used in the area, place the most commonly used 
> language in the name=* field and then the other languages in the appropriate 
> name:en=*, name:fr=*, and so on. This will ensure that the data is 
> specifically catalogued for routing software, while providing the opportunity 
> for users of data to specify the language they desire to read the map in. In 
> the end I suppose it would just be a matter of seeing both all the time or 
> not but if we use the name:(insert whatever desired language here)=* we 
> ensure a more specific and catalogued database for OSM globally.
>
> An example of this the Greek method where they have
> name=Μητροπόλεως
> name:el=Μητροπόλεως
> name:en=Mitropoleos street
>
> In Greece if I use a routing software, I can easily tell it to show me 
> name:en or name:el for whatever I need to see at the time. Rather then using 
> hyphen, slash or space I propose we use this method for distinguishing 
> different translations in our naming scheme

I think it depends on whether the language of the second name on the
street sign is spoken at that place or not, i.e. if it is a bilingual
place or not. If it is not – like in Greece –, then I think your
example makes sense. However, if it is – like for example in
Biel/Bienne [^1] – then I would put both names in the name=* tag.

[^1]: 

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

Re: [Tagging] residents only after hours

[SelfishSeahorse]

PS: Or, in case access is granted only to pedestrians:
>
>
foot=destination
foot:conditional=yes @ (Oct-Apr 07:00-20:00; May-Sep 07:00-22:30)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] residents only after hours

[SelfishSeahorse]

On Saturday, August 18, 2018, Jmapb  wrote:
>
>
> Any particular reason to include the day numbers rather than just using
> the month name to indicate the whole month?
>

The reason is i forgot to remove the day numbers when copy-pasting. :-) You
can omit them (but you don't have to).:

access=destination
access:conditional=yes @ (Oct-Apr 07:00-20:00; May-Sep 07:00-22:30)

Sorry for the confusion.

BTW: You can add a colon after the month range for readability, as you did
in your initial e-mail, but it's optional.

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

Re: [Tagging] How to tag small canals?

[SelfishSeahorse]

Hi

I've written an issue request on openstreetmap-carto regarding the too
thick canal rendering:
https://github.com/gravitystorm/openstreetmap-carto/issues/3354

Regards
Markus
On Thu, 16 Aug 2018 at 18:20, Christoph Hormann  wrote:
>
> On Thursday 16 August 2018, Martin Koppenhoefer wrote:
> > >
> > > All of this together has its origin in the fact that in the UK and
> > > other early OSM countries large artificial waterways are almost
> > > always for navigation and small artificial waterways are almost
> > > always for transporting away undesirable water.
> >
> > +1
> > That’s my analysis as well. What do you think, shouldn’t we fix the
> > wiki to make it more universally applicable to all kinds of
> > waterways?
>
> As usual i don't think you can change the definition of tags that are
> already used hundreds of thousands of times except by extending their
> scope which would make the tags more vague than they already are.
>
> What would make sense is to explicitly mention that waterway=canal does
> not have a lower size.
>
> Inventing a separate tagging scheme for irrigation systems might be an
> option too but irrigation is performed in very different ways in
> different parts of the world so it might not be too easy to create an
> universal tagging system for that.
>
> > The canal definition was changed in March 2018, before it said to use
> > canal only for „the largest waterways created for irrigation
> > purposes“
>
> Yes, that was the obvious attempt to expand the narrow scheme to other
> parts of the world in a superficial way oriented at the standard style
> rendering but not at the actual semantics.
>
> Going this route would essentially mean turning all of ditch/drain/canal
> into one big uniform catch-all.  Removing the above is the attempt to
> salvage some of the semantic value in the data.  Not sure how
> successful that is without support from the standard style though.
>
> Unfortunately waterway=canal has only 13k combinations with width=* and
> only 1.8k combinations with usage=* at the moment.  Extending that
> would be the best way to move forward IMO.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

[Tagging] How to tag small canals?

[SelfishSeahorse]

On Friday, August 17, 2018, Christoph Hormann  wrote:

> On Friday 17 August 2018, SelfishSeahorse wrote:
>
> > Of course we could just use width=*, but it's not always easily
> > possible to measure the width (e.g. in a forest) and sometimes it
> > changes often.
>
> I would translate this into "i want a subjective non-verifiable
> classification system but i hide this by defining pro forma verifiable
> criteria for the classes".


A classification based on width is arbitrary, but i don't see why it be
subjective.

If you want to map the river width tag width=*, if you don't want to map
> the width then don't create classes based on width thresholds.
>

Imagine a stream/brook in a forest, not visible on satellite imagery. You
can't measure its width on site (because you don't have the equipment or
because the soil at its sides is marshy), but you know (estimate) that it's
wider than 1 metre, but less wide than 3 metres. In my opinion it's better
to have that information that none.

If you enter width="1 m - 3 m", data users very likely won't understand it.
However if you enter width="2 m", the width value pretends to be exact.
Besides it is very unlikely that someone else verifies that value,
considering the fact that less than 1% of waterway=* tags have a width=*
tag.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] residents only after hours

[SelfishSeahorse]

On Tue, 21 Aug 2018 at 19:33, Greg Troxel  wrote:
> If it's private, then access=yes is arguably not right, as permission is
> granted to the public, vs the public having a right of access.
>
> So I would use
>
> access=permissive
>
> instead of yes.  But this is a far larger issue than this one place; it
> arguably applies to all paths on private land (that aren't a public
> right-of-way of course) where it's basically ok for the public to go.

You are right, i was wrong. :-) Thanks for correcting me!

access=destination
access:conditional=permissive @ (Oct-Apr 07:00-20:00; May-Sep 07:00-22:30)

Regards
Markus

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

Re: [Tagging] residents only after hours

[SelfishSeahorse]

Hi

On Friday, August 17, 2018, Jmapb  wrote:

> I've got a pedestrian way behind a large apartment building (leads to a
> back entrance) that's restricted to residents only after hours. Or more
> precisely, it's signed "Open to the public Oct 1 - Apr 30 7am-8pm, May 1 -
> Sep 30 7am-10:30pm."
>
> My best guess at tagging is:
> access=yes
> access:conditional=destination @ (Oct-Apr: 20:00-07:00; May-Sep:
> 22:00-07:00)
>

Because you wrote that it's a pedestrian way, i guess the access
restriction only applies to pedestrians. In that case you should use
foot[:conditional]=* instead of access[:conditional]=*, otherways you also
give access to vehicles, horses etc.

Besides, i think you shoul rather go from the most restrictive to the least
restrictive, i.e.:

foot=destination
foot:conditional=yes @ (Oct 1-Apr 30 07:00-20:00, May 1-Sep 30 07:00-22:30)

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

Re: [Tagging] residents only after hours

[SelfishSeahorse]

On Saturday, August 18, 2018, SelfishSeahorse 
wrote:

>
> foot=destination
> foot:conditional=yes @ (Oct 1-Apr 30 07:00-20:00, May 1-Sep 30 07:00-22:30)
>

Sorry, i've made a mistake: there should be a semicolon instead of a comma:

foot:conditional=yes @ (Oct 1-Apr 30 07:00-20:00; May 1-Sep 30 07:00-22:30)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] landcover=asphalt ; landuse=highway

[SelfishSeahorse]

On Fri, 13 Jul 2018 at 15:38, Leo Gaspard  wrote:
> These tags has already been put forth in the landcover proposal [1], but
> I was just pointed to [2] where a user complained (rightfully) that the
> shape of the road on OSM mismatched the shape of the actual road.

> [2] https://www.openstreetmap.org/note/1387860

I think that the mapping of the streets at that location still doesn't
reflect reality well: I'd expect there to be separated carriageways,
which isn't the case. This also has a negative effect on routing, e.g.
see:



This is how I would map the situation:



Regards, Markus

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

[Tagging] Transport mode on platforms? (Was: Re: Documentation issues of PT tagging schemes)

[SelfishSeahorse]

Hi

It seems that the only problem with PTv2 that remains is the rendering
of public_transport=platform, i.e. whether public_transport=platform
(and maybe public_transport=station too) should get the transport mode
tag(s) (bus=yes/tram=yes/...).

Note that the PTv2 proposal suggested to map the *stop position* 'as
an icon depending of the vehicle type that is stopping at the
position',[1] which may have led to some people mapping only
stop_position's, others mapping only platform's and still others
mapping stop_position's and platform's which in turn has led to
complication and confusion.

[1]: https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport_v3

As this question pops up every now and then, it might make sense to
finish discussing this.

I'm double posting this message on the transport mailing list, so that
the discussion can continue there.

Regards
Markus

On Wed, 25 Jul 2018 at 19:25, Roland Olbricht  wrote:
>
> Hi,
>
> > What I would like to see is how to map a Public Transport Route in
> > version 3 .. that has the bear minimum of things to have and the rules
> > that make the route valid.
>
> This is where the problem sits; the point of view of what a route is
> vary wildly. Few people are even willing to pinpoint and tell their
> personal definition.
>
> Things that exist under the notion of route:
>
> - Urban bus/tram/subway services (many stops, many departures, route
> taken always or almost always the same, route through the street grid
> practically fixed, often unchanged for years to decades)
>
> - Peak services, special routes to depot, school services (few
> departures, many stops, also many route variants, frequently changing,
> making it impractical to route them all)
>
> - Hail bus services: the bus is promised to serve a certain street and
> stops on hail (many departures, route taken always or almost always the
> same, route through the street grid practically fixed, often unchanged
> for years to decades)
>
> - Urban and regional train lines (many stops, many departures, route and
> platforms fixed). Those routes are often in parts or completely land marks.
>
> - Long distance train lines (many stops, many departures, route and
> platforms may or may not vary, can stop at a different platform of the
> same station for operational reasons)
>
> - Long distance bus services (few stops, few departures, route between
> stops often changing on the fly)
>
> - Ferry lines (often only two stops, completely different
> infrastructure)
>
> Further kinds of routes may exist. For example, some communties use
> virtual metro lines that connect station node to station node. This is
> most often because the communties lack the ressources to map the actual
> underground structures.
>
> I personally map only urban bus/tram/subway services and urban and
> regional train lines (and do not delete other routes). For these
> services it is sane to have marked the stops and the route on the grid.
>
> The route on the grid is straightforward: this is in any PT scheme a
> sequence of way members that together form a continuous trajectory. Hail
> sections get a special role for these members.
>
> The stop part is more tricky. I personally add one element for each stop
> where the bus/train is calling, using the role "platform". The member
> element should have the tag "name" set to ensure meaningful usage and
> pain-free editing of the route.
>
> The minimum required tags on the relation are "ref=",
> somtimes "name=", and "type=route" + "route=bus" for buses.
>
> Please do not forget that a more detailed explaination fits better on
> the transit list
> https://lists.openstreetmap.org/listinfo/talk-transit
> I would suggest to continue the discussion there, but Ilya has for
> unknown reason fear of the talk-transit list. It makes sense to give him
> an easy opportunity to answer.
>
> I read Ilya's proposal such that he wants to feature the virtual metro
> lines, at the expense of mandating to map hail services as empty
> relations. But it would be better if he tells us himself.
>
> Best regards,
> Roland
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Properties of swimming pools

[SelfishSeahorse]

On Thu, 30 Aug 2018 13:13 dktue,  wrote:

> I would like to tag information about the water-temperature and the
> depth of the separate pools in the outdoor-swimming pool [1]. Are there
> any suggested tag-names or should I just go with "depth" and "temperature"?
>

In case the pool depth varies, you might want to tag min_depth and
max_depth instead.

Regarding temperature: is it more or less stable (perhaps heated pools)?
The temperature of the outdoor swimming pools i know vary quite a bit
during summer (usually 17-24 °C).

Regards, Markus

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

Re: [Tagging] Slow vehicle turnouts

[SelfishSeahorse]

On Sat, 8 Sep 2018 at 02:38, Paul Johnson  wrote:
> I'm thinking, perhaps, a new access tag value: smv (slow moving vehicle).  
> Then you could (using my previous I 82 through the Cabbage Patch climb) do 
> something like smv:lanes:access=no|yes|designated.

This seems like a good idea to me -- although 'slow moving vehicle' is
defined differently depending on the region (e.g. < 60 km/h in France
or less than the normal speed at the particular time and place in the
USA or CA), but that shouldn't be our problem, should it?

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

Re: [Tagging] Slow vehicle turnouts

[SelfishSeahorse]

On Sun, 9 Sep 2018 at 12:15, Philip Barnes  wrote:
> The only signage on autoroute with voie pour vehicules lents is the start of 
> a new crawler lane in English and a sign indicating 'vehicules lents'. There 
> is no indication of a maximum speed for that lane, beyond at 130 you may come 
> up behind a truck very quickly, there is no indication that the standard keep 
> to the right unless overtaking doesn't apply. [...]

The 60 km/h are not indicated on the road sign, but in the 'Code de la
route' (highway code):

https://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI06842322=LEGITEXT06074228

The second section is translated into English as follows: 'For the
purposes of this article, the term slow vehicles refers to vehicles
that cannot travel at a speed exceeding 60 km/h on the road section in
question.'

But because our good practice guidelines recommend to not map local
legislation, this doesn't seem to matter, and smv:lanes=||designated
should be fine. (I wouldn't even tag smv:lanes=no|yes|designated
because of the same guideline.)

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

Re: [Tagging] Slow vehicle turnouts

[SelfishSeahorse]

On Mon, 10 Sep 2018 at 11:17, Dave Swarthout  wrote:
> I'm still not convinced the lanes:smv tagging scenario is the best solution 
> but were I to change my mind, how would I tag my turnouts?  Here is another 
> screen shot of the particular section of highway with a turnout on both sides 
> of the road that I've been discussing (59.752103, -151.766395 ) with the ways 
> removed for clarity: 
> https://www.dropbox.com/s/nm6iahw9ch79tuh/slow_vehicle_turnout.jpg?dl=0

I would probably split the road at every place where an additional
lane begins or ends, i.e. four times, and would tag the sections as
follows from right to left (this is the direction of the highway way):

lanes=2

lanes=3
lanes:forward=2
lanes:backward=1
smv:lanes:forward=|designated
overtaking:lanes:forward=yes|no

lanes=4
lanes:forward=2
lanes:backward=2
smv:lanes:forward=|designated
smv:lanes:backward=|designated
overtaking:lanes:forward=yes|no
overtaking:lanes:backward=yes|no

lanes=3
lanes:forward=1
lanes:backward=2
smv:lanes:backward=|designated
overtaking:lanes:backward=yes|no

lanes=2

In case the turnouts were separated by a barrier, i think your idea
with highway=service + service=slow_vehicle_turnout would make sense.

Regards
Markus

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

Re: [Tagging] Slow vehicle turnouts

[SelfishSeahorse]

You're welcome!

I understand that the lanes method is time-consuming. Alternatively, you
could skip the three lines section as it is rather short. Then you would
just have to split the road way twice and copy-paste the tags. I think this
is even faster than drawing and tagging two additional ways.


On Mon, 10 Sep 2018 15:15 Dave Swarthout,  wrote:

> Wow, thanks for the help, Markus. I really appreciate it.
>
> But I must say, if I have to use that method to tag all the turnouts on
> the Sterling Highway, I'm going to leave them unmapped. Life is too short
> and there is a lot of other mapping yet to do in Alaska.
>
> Although these lanes are not physically separated by a barrier other than
> a painted line, I'm going to opt for the service road scenario. It is
> simple, much, much less error prone to map, and IMHO, would do the job
> better than the lanes technique.
>
> Thanks to all,
>
> Dave
>
> On Mon, Sep 10, 2018 at 6:51 PM SelfishSeahorse 
> wrote:
>
>> On Mon, 10 Sep 2018 at 11:17, Dave Swarthout 
>> wrote:
>> > I'm still not convinced the lanes:smv tagging scenario is the best
>> solution but were I to change my mind, how would I tag my turnouts?  Here
>> is another screen shot of the particular section of highway with a turnout
>> on both sides of the road that I've been discussing (59.752103, -151.766395
>> ) with the ways removed for clarity:
>> https://www.dropbox.com/s/nm6iahw9ch79tuh/slow_vehicle_turnout.jpg?dl=0
>>
>> I would probably split the road at every place where an additional
>> lane begins or ends, i.e. four times, and would tag the sections as
>> follows from right to left (this is the direction of the highway way):
>>
>> lanes=2
>>
>> lanes=3
>> lanes:forward=2
>> lanes:backward=1
>> smv:lanes:forward=|designated
>> overtaking:lanes:forward=yes|no
>>
>> lanes=4
>> lanes:forward=2
>> lanes:backward=2
>> smv:lanes:forward=|designated
>> smv:lanes:backward=|designated
>> overtaking:lanes:forward=yes|no
>> overtaking:lanes:backward=yes|no
>>
>> lanes=3
>> lanes:forward=1
>> lanes:backward=2
>> smv:lanes:backward=|designated
>> overtaking:lanes:backward=yes|no
>>
>> lanes=2
>>
>> In case the turnouts were separated by a barrier, i think your idea
>> with highway=service + service=slow_vehicle_turnout would make sense.
>>
>> Regards
>> Markus
>>
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Slow vehicle turnouts

[SelfishSeahorse]

I wasn't aware that it is allowed to cross a single solid line in the
USA. Hence forget the overtaking:lanes:=* tags in
the example in my last message.
On Mon, 10 Sep 2018 at 20:38, Paul Johnson  wrote:
>
> I see it as a variation on no turn on red/turn after stop OK on red 
> dichotomy.  Not really significant enough to bring up in the map data 
> specifically, so long as the signal itself is mapped.  And the single white 
> line seems to not be of special significance in most cases, only meaning that 
> you need to use additional caution when changing lanes (as opposed to double 
> white lines, where lane changes in one or both directions is prohibited).
>
> On Mon, Sep 10, 2018, 13:29 Tobias Wrede  wrote:
>>
>> The solid line is a special case. So many other turn-outs/climbing lanes/... 
>> have a dashed line or even no line at all. I wouldn't make a difference 
>> based on markings.
>>
>> I also strongly favor the lines solution but wonder if we could not stretch 
>> the turn key a bit. Something along turn:lanes:forward=through|turn-out.
>>
>> /Tobi
>>
>>
>> Am 10.09.2018 um 19:54 schrieb Paul Johnson:
>>
>> I don't think so.  Really the only thing throwing this off seems to be the 
>> same thing throwing off people who think bus and bicycle lanes shouldn't be 
>> counted as lanes: the solid line.
>>
>> On Mon, Sep 10, 2018, 11:50 Kevin Kenny  wrote:
>>>
>>> It seems to me that the key attribute of the 'climbing lane' situation
>>> that Dave mentions is that it's an additional lane. It's provided for
>>> slow-moving vehicles, sure, but that's really a special case of the
>>> near-universal convention that slow-moving traffic gives way to
>>> overtaking traffic by moving to the outside (that is, in North
>>> America, to the right). The difference, at least where I am, between a
>>> climbing lane and another ordinary lane is a subtle one: you don't
>>> have to move to the outside if nobody's trying to overtake, rather
>>> than a "keep right except to pass" rule. You get 90% of the way there
>>> by simply having the correct number of lanes:forward and
>>> lanes:backward. Is adding a lane that much more complicated than
>>> drawing a parallel way?
>>> On Mon, Sep 10, 2018 at 11:31 AM Joseph Eisenberg
>>>  wrote:
>>> >
>>> > I'd say that it would be better to leave them unmapped than to 
>>> > incorrectly map them as separate service roads.
>>> > If they are only divided by a single painted line, they are just lanes, 
>>> > not a separate roadway.
>>> > And it's not too difficult to split the way twice and paste on a couple 
>>> > of tags
>>> >
>>> > On Mon, Sep 10, 2018 at 10:17 PM Dave Swarthout  
>>> > wrote:
>>> >>
>>> >> Wow, thanks for the help, Markus. I really appreciate it.
>>> >>
>>> >> But I must say, if I have to use that method to tag all the turnouts on 
>>> >> the Sterling Highway, I'm going to leave them unmapped. Life is too 
>>> >> short and there is a lot of other mapping yet to do in Alaska.
>>> >>
>>> >> Although these lanes are not physically separated by a barrier other 
>>> >> than a painted line, I'm going to opt for the service road scenario. It 
>>> >> is simple, much, much less error prone to map, and IMHO, would do the 
>>> >> job better than the lanes technique.
>>> >>
>>> >> Thanks to all,
>>> >>
>>> >> Dave
>>> >>
>>> >> On Mon, Sep 10, 2018 at 6:51 PM SelfishSeahorse 
>>> >>  wrote:
>>> >>>
>>> >>> On Mon, 10 Sep 2018 at 11:17, Dave Swarthout  
>>> >>> wrote:
>>> >>> > I'm still not convinced the lanes:smv tagging scenario is the best 
>>> >>> > solution but were I to change my mind, how would I tag my turnouts?  
>>> >>> > Here is another screen shot of the particular section of highway with 
>>> >>> > a turnout on both sides of the road that I've been discussing 
>>> >>> > (59.752103, -151.766395 ) with the ways removed for clarity: 
>>> >>> > https://www.dropbox.com/s/nm6iahw9ch79tuh/slow_vehicle_turnout.jpg?dl=0
>>> >>>
>>> >>> I would probably split the road at every place where an additional
>>> >>> lane begins or ends, i.e. four times, and would tag the sections as
>>>

Re: [Tagging] mast / tower / communication_tower (again)

[SelfishSeahorse]

On Sun, 30 Sep 2018 at 17:24, SelfishSeahorse  wrote:
>
> On Sun, 30 Sep 2018 at 14:45, Martin Koppenhoefer
>  wrote:
> >
> > > To solve the contradiction we need to get rid of one of the two 
> > > definitions.
> >
> > they could be combined: if it is intended to be accessed by people (not 
> > only for maintenance) and is not guyed it is a tower, otherwise it would be 
> > a mast.
>
> I think it's better to stick to either a common or a technical
> definition. OSM-specific definitions are prone to create confusion and
> tagging mistakes.

PS: Except if this appears to be a common definition.

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

Re: [Tagging] mast / tower / communication_tower (again)

[SelfishSeahorse]

On Sun, 30 Sep 2018 at 19:34, Martin Koppenhoefer
 wrote:
>
> > I think it's better to stick to either a common or a technical
> > definition.
>
>
> it doesn’t have to be the British definition of terms, has it?

It would already be helpful if there actually were a common definition
to distinguish masts from towers.

By the way, i've written a message to the person who added the
definition to the wiki that 'a tower is accessible and provides
platforms, whereas a mast only offers ladder steps to climb it' [1]
and asked him where this definition comes from and what 'accessible'
exactly means (a ladder also provides access).

[1]: 
https://wiki.openstreetmap.org/w/index.php?title=Tag:man_made%3Dmast=next=795248

Regards
Markus

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

[Tagging] mast / tower / communication_tower (again)

[SelfishSeahorse]

On Friday, October 5, 2018, Graeme Fitzpatrick 
wrote:
>
>
> I don't know how many of the 3500 worldwide are actually
> communications_towers bu that definition, but I'd guess not more than a
> dozen or 2?
>

There are already more than a dozen in the small country of Switzerland.


> I'd like to suggest that we deprecate that tag, settle on the engineering
> definition given to differentiate between masts & towers:
>
> "In structural engineering, *mast* is a vertical structure, supported by
> external guys and anchors.
> This is the only existing definite feature that could be used to
> differentiate masts and towers."
>
> & start cleaning things up.
>
> Your thoughts?
>

If this is the only common differentiation between masts and towers, then i
don't disagree using it.

However i'm wondering how many radio masts/towers have been tagged
according to the distinction latter outside vs steps/lift inside.

Besides, for people like me that are really bad at estimating height, but
still want to differentiate small mobile phone 'towers' like [1] from big
TV towers like [2], i think it would make sense to use a tag like
tower:access=inside/outside.

[1]:
https://commons.m.wikimedia.org/wiki/File:Mobile_Phone_Mast_near_Gore_-_geograph.org.uk_-_1703520.jpg
[2]:
https://commons.m.wikimedia.org/wiki/File:Aerial_view_-_Fernsehturm_St._Chrischona5.jpg

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

Re: [Tagging] Ignore roundabout flare in counting

[SelfishSeahorse]

On Friday, October 5, 2018, Florian Lohoff  wrote:

>
> Is there tagging to let announcements ignore that flare?
>

I think that if the driveway is tagged highway=service, this should be
enough information for the routeing engine to ignore it. Besides there
might be people that don't want the driveway to be ignored.

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

Re: [Tagging] How to tag named group of named water areas?

[SelfishSeahorse]

On Sun, 7 Oct 2018 at 18:08, Mateusz Konieczny  wrote:
>
> - way with natural=water and name="Small Pond"
> - way with natural=water and name="Big Pond"
> - relation grouping this ways with name="Groble" and proper type
>
> But how relation should be tagged?
>
> Tagging it natural=water seems wrong to me - as result water areas would be 
> tagged twice.
>
> But maybe it would be OK?
>
> If water is supposed to not be tagged twice - maybe use something like
> place=water_areas? But it seems not better to me.

What about a new type=group relation that would inherit the properties
of its members (as opposed to a type=multipolygon relation)?

Regards
Markus

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

Re: [Tagging] How to tag named group of named water areas?

[SelfishSeahorse]

On Mon, 8 Oct 2018 at 13:13, Martin Koppenhoefer  wrote:
>
> A very similar problem are parts of lakes by the way, e.g. look at this map 
> of the lake of Constance, showing names for parts of the lake: 
> https://de.wikipedia.org/wiki/Bodensee#/media/File:Bodensee_satellit%2Btext.png
> (or maybe the "lake" in this case is a group of lakes as well).

This problem could be solved with *:part=* areas (in this example
natural:part=lake), analogous to building:part=*.

Regards
Markus

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

Re: [Tagging] mast / tower / communication_tower (again)

[SelfishSeahorse]

On Sun, 30 Sep 2018 at 14:39, SelfishSeahorse  wrote:
>
> That is, we have two contradictory definitions on the wiki: the
> engineering definition according to which a tower is freestanding and
> mast guyed, and the other definition according to which 'a tower is
> accessible and provides platforms, whereas a mast only offers ladder
> steps to climb it'. (Where does this latter definition come from?)

I've just came across this article on the German Wikipedia [1] that
defines towers and masts similar to our non-engineering definition
mentioned above (translated with www.deepl.com/translator):

> A tower is a vertically aligned structure which can be walked on and which is 
> defined by its height. This means that its height is either a multiple of its 
> diameter or its thickness and/or it clearly towers above the surrounding 
> buildings or adjacent components.
>
> The term tower is to be distinguished on the one hand from the term 
> skyscraper, on the other hand from the term mast, whereby the exact 
> delimitation is often not possible, partly there are intersections, depending 
> upon context different definitions or linguistic blurriness. For example, 
> bell or church towers are usually referred to as towers even if they are not 
> accessible.
>
> In radio technology in particular - in contrast to a mast (transmitter mast), 
> which is often designed as a truss construction - a tower (transmitter tower) 
> is understood to be a accessible, not spanned (i.e. not anchored with guys) 
> upright cantilever construction.

[1]: https://de.wikipedia.org/wiki/Turm

There is a risk that towers and masts are defined differently in
English, but perhaps Martin's idea to combine the two definitions
would make sense nevertheless.

Regards
Markus

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

Re: [Tagging] How to tag named group of named water areas?

[SelfishSeahorse]

On Mon, 8 Oct 2018 at 21:16, Tod Fitch  wrote:
>
> I had not noticed the existence of the group relation before. Seems to me 
> that it and the controversial site relation have some overlap. For the 
> examples I can think of where I think the site relation works it seems like 
> the group relation would also work. So, at present and lacking 
> counter-examples, it seems to me that one of these two relations should go 
> away.

There is quite some difference between the suggested group relation
and a site relation:

A site relation is an own feature that consists of several other
features. (For example, a wind farm cannot be mapped as a power plant
area, but it can be mapped as a power plant site relation with
multiple wind turbines as members.[1])

[1]: https://www.openstreetmap.org/relation/3792332

In contrast, a group relation isn't a separate feature, but just a
name; the feature is already defined for its members. (Like in our
example the two ponds 'Small Pond' and 'Big Pond' that together are
called 'Groble'.)

This is also why a site (or multipolygon) relation wouldn't work in our example.

Regards
Markus

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

Re: [Tagging] Dispensing vs vending (Was: Combined waste/recycling bins)

[SelfishSeahorse]

On Thu, 11 Oct 2018 at 11:28, Martin Koppenhoefer
 wrote:
>
> no, I would remove only those from "vending", which are not about vending. 
> E.g. parcels and excrement bags. Those that are about dispensers could get a 
> dispensing tag, those that offer completely different services like parcel 
> drop off should get proper tags that describe the thing.

What about

amenity=parcel_station
parcel_station:send=yes/no
parcel_station:receive=yes/no

?

Regards
Markus

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

Re: [Tagging] opening_hours value question

[SelfishSeahorse]

Hi!

On Fri, 12 Oct 2018 at 13:33, John Willis  wrote:
>
> - Can someone type me the necessary tag value for such a monthly calendar 
> dependant item? "Open on the 3rd Saturday from 10am-1pm"

The n-th weekday of the month can be written by appending the number
(1 for 1st, 2 for 2nd, ..., -1 for last) enclosed in square brackets
to the weekday (Mo-Su). Thus 'open on the 3rd Saturday from 10am-1pm'
translates as:

Sa[3] 10:00-13:00

> - also, is there a way to positively define "closed Tuesdays" or similar? It 
> may not be necessary, but it is a common thing to see, hopefully it is easy 
> to tag.

You can:

Tu closed (or synonymously: Tu off)

For example 'open every day from 09:00 to 18:00, but closed on
Tuesdays' can be written:

09:00-18:00; Tu closed

But i personally prefer it the other way around:

We-Mo 09:00-18:00 (or Mo,We-Su 09:00-18:00)

'closed' is only indispensable if you want to override a previously
defined rule, for example:

Mo-Sa 09:00-18:00; PH closed

which means 'open every day from Monday to Saturday from 09:00-18:00
but closed on public holidays'.

> Thanks in advance

You're welcome.

Regards
Markus

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

Re: [Tagging] Feature Proposal - RFC - landuse=governmental

[SelfishSeahorse]

Thank you, Joseph and Warin, for your feedback!

On Sun, 14 Oct 2018 at 04:02, Joseph Eisenberg
 wrote:
>
> However, I'm not sure that "governmental" is the best value for the landuse 
> key. I think there would be a risk of mappers finding this tag in the editors 
> and using it for all governnment-owned land, not just for administrative 
> offices. [...] For these reasons, I believe the current tag 
> "landuse=civic_admin" or "landuse=public_administration" are a little better. 
> [...]

I'm aware of this risk and i was quite undecided between
landuse=governmental and landuse=public_administration.
public_administration isn't unproblematic too, because, if i'm not
mistaken, legislature facilities (places where
assembly/parliament/congress meets) and courts are another divisions
of government and don't belong to the public administration. But
dividing land used for governing would complicate mapping too much in
my opinion.

Any more opinions on that point? I'd be fine with changing the tag to
landuse=public_administration if other people think that this tag is
better.

> Also, in the proposal, it is stated that this tag will not be used for 
> "Public service facilities"
> What is the definition of a "public service facility" as opposed to "public 
> administration offices?"

You're right, 'public service facility' was unclear. I was thinking of
public service facilities that aren't directly involved in or
responsible for governing or organising the country, state or
municipality (or any other administrative division), but that have
other purposes like educating people, caring for their health,
offering them leisure activities etc. These should be excluded from
landuse=governmental.

Consequently, the Public Health Department would be
landuse=governmental, but not public health facilities like hospitals,
clinics or doctor's practices.

I've updated the proposal page.

On Sun, 14 Oct 2018 at 12:00, Warin <61sundow...@gmail.com> wrote:
>
> I think that there first need to be clear definitions of what are:
>
> public administration
> executive
> Legislature
> Judiciary (courts)

I'm going to try improving and adding definitions.

> and where things fit...
>
> police (national, state, municipal)
> military - excluded?
> libraries (national, state, municipal)
> schools - excluded?
> post office - excluded?

These facilities would all be excluded because they have different
purposes than governing or organising the country, state or
municipality. (I'm thinking of proposing landuse=educational later.)

> tax office
> vehicle licence office

These would be included.

> Do these all need to be combined? That does suit places where they are 
> physically combined ... and if people then want to further identify them then 
> sub tags could be used.
>
> As for the word to use... that will come, after the definitions?

There's landuse=institutional, [3] but this tag overlaps with
landuse=military which is already in use ... And i don't know how to
name such a land use differently.

[3] https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dinstitutional

I suggest to tag the main use for places with mixed land use, probably
the land use that uses the most space. For example, if there's a small
police station or post office in a city hall, i'd still tag it
landuse=governmental or landuse=public_administration. There will
always be places with mixed land use, probably the most common example
being buildings with shops on the ground floor and apartments on the
upper floors.

Regards
Markus

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

Re: [Tagging] Feature Proposal - RFC - landuse=governmental

[SelfishSeahorse]

Hi!

On Sun, 14 Oct 2018 at 17:16, marc marc  wrote:
>
> > But dividing land used for governing would complicate mapping too much
>
> why not ? school/education and military already exist.

Because at least offices of the public administration and the
executive body are often located in the same building.

> office also have already have landuse=commercial
> and we may add a subtag like commercial=government.
> so maybe we only need landuse=executive legislature judicial

commercial=government is a contradiction. Note that the wiki already
says that 'government services and businesses should not use this tag
[landuse=commercial].':

https://wiki.openstreetmap.org/wiki/Key:landuse

Regards
Markus

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

Re: [Tagging] Feature Proposal - RFC - landuse=governmental

[SelfishSeahorse]

On Sun, 14 Oct 2018 at 20:35, Tom Hardy  wrote:
>
> Just to throw a couple more your way:
>
> https://www.openstreetmap.org/way/622149574
> landuse=garages is a staging area for city public works and county truck
> repair, and
>
> https://www.openstreetmap.org/way/448672572
> amenity=recycling is for city run recycling of yard waste
>
> I couldn't find exactly appropriate tagging so I think I used a sort of least
> appropriate method.

The tagging seems fine to me.

> Is it time to consider some sort of general overhaul of landuse to make it
> more flexible?

Are you thinking of a system with sub-keys? Not sure if a general
overhaul is necessary, but land use (as well as land cover) certainly
has room for improvement: there are missing land uses (e.g. the
proposed governing area or forestry) and some of the current tags are
problematical and confusing (e.g. retail, which actually is a subset
of commercial).

By the way, if someone is interested, i've recently made a table
comparing land use categories from the UK's National Land Use Database
with OSM's landuse tags:

https://wiki.openstreetmap.org/wiki/Proposed_features/landuse%3Dgovernmental

Regards
Markus

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

Re: [Tagging] Feature Proposal - RFC - landuse=governmental

[SelfishSeahorse]

Hi, Martin!

On Mon, 15 Oct 2018 at 01:09, Martin Koppenhoefer
 wrote:
>
> So police stations are out? The ministry of defense is in, but the 
> subordinate units of it are out (because military)? Courts are in? Prisons? 
> Storage (e.g. 
> https://en.m.wikipedia.org/wiki/Global_strategic_petroleum_reserves )?
>
> What about publicly owned companies? Does it matter whether they are 100% 
> public, 50% or only 30%?
> Do I understand it correctly that this is for all governmental places 
> regardless of the actual use, like offices, laboratories (public health 
> department, other public institutes)?

No, landuse=governmental is intended for the land used for organising
a country, state, municipality etc., that is, the 'core functions' of
a country, state, municipality etc., which are administering it,
making rules (laws), interpreting and executing them. Therefore only
public administration offices, meeting places of the assembly, courts
and offices of the executive are included in landuse=governmental.
Other governmental services that have different purposes than
organisation (e.g. police stations, prisons, public schools or
hospitals) are excluded from landuse=governmental.

landuse=governmental is about the purpose, that is governing, not the
operator or owner.

I agree that landuse=governmental isn't a very clear tag, but i
haven't been able to find a better one. As mentioned earlier, while
landuse=public_administration would be the most comprehensible, it is,
strictly speaking, only one part of the government. I'm not sure if it
would be a good idea to also tag meeting places of parliaments
landuse=public_administration. Instead defining separate landuse tags
for public administration, executive, parliament and courts doesn't
seem to be practicable either, as many countries don't distinguish
between law making (legislature/parliament) and law executing
(executive) and because at least public administration and executive
are often located within the same building (especially on municipal
level).

What you were thinking of sounds like the very broadly defined
landuse=institutional, which includes facilities with a wide variety
of purposes. [1] If we went that way, we would need sub-tags
(including for military area, i.e. landuse=institutional +
institutinal=military instead of landuse=military). However, the
problem of how to call the sub-tag(s) for public administration,
executive, parliament and courts were exactly the same as without
landuse=institutional + sub-tags.

[1]: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:landuse%3Dinstitutional

Regards
Markus

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

Re: [Tagging] Feature Proposal - RFC - landuse=governmental

[SelfishSeahorse]

On Mon, 15 Oct 2018 at 22:32, SelfishSeahorse  wrote:
>
> However, the problem of how to call the sub-tag(s) for public administration, 
> executive, parliament and courts were exactly the same as without 
> landuse=institutional + sub-tags.

PS: The only benefit i see of landuse=institutional + sub-tags are
mixed-use institutional areas (e.g. public administration offices and
a police station being located in the same building).

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

Re: [Tagging] Feature Proposal - RFC - landuse=governmental

[SelfishSeahorse]

On Sun, 14 Oct 2018 at 17:42, SelfishSeahorse  wrote:
>
> Because at least offices of the public administration and the
> executive body are often located in the same building.

PS: Public administration is actually considered being a part of the executive.

Do you or anyone else have another idea how to name land used for
governing or how to solve this problem differently? It doesn't seem to
be an easy task ...

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

[Tagging] Feature Proposal - RFC - landuse=governmental

[SelfishSeahorse]

Hello everyone!

I am proposing a new tag, landuse=governmental, for marking land that
is used for governing:

https://wiki.openstreetmap.org/wiki/Proposed_features/landuse%3Dgovernmental

Regards
Markus

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

Re: [Tagging] Dispensing vs vending (Was: Combined waste/recycling bins)

[SelfishSeahorse]

On Sat, 13 Oct 2018 at 17:03, Martin Koppenhoefer
 wrote:
>
> > amenity=parcel_station
> > parcel_station:send=yes/no
> > parcel_station:receive=yes/no
>
>
> +1, would be fine for me.
> or amenity=parcel_machine?

I'm indifferent to the tag name. Other possibilities are parcel locker
or parcel terminal. Some statistics from Google:

"parcel locker": about 200.000 results
"parcel terminal": about 153.000 results
"parcel station": about 109.000 results
"parcel machine": about 41.400 results

Maybe parcel locker is the most descriptive one.

> I believe packstation is a trademark

In any case it seems that only DHL (Germany) uses this term. (I've
never heard it. They're called 'My Post 24' in CH.)

On Sat, 13 Oct 2018 at 17:40, Martin Koppenhoefer
 wrote:
>
> maybe it would be better to use more universally applicable tags like
> parcel:sending
> parcel:pickup

Good idea!

Regards
Markus

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

Re: [Tagging] mast / tower / communication_tower (again)

[SelfishSeahorse]

On Tue, 9 Oct 2018 at 16:07, Greg Troxel  wrote:
>
> The guy wires or not is made into the main thing here, but it's really a 
> detail.

Obviously, from a certain height, tall cylindrical structures like
masts need guy-wires for stabilisation. Otherwise, they need a larger
diameter or a conical shape. Thus, the presence of guy-wires is an
indicator for masts but not a requirement.

Imho, the current definition on the wiki according to which a tower
has internal access or platforms is practical and quite sensible.

Regarding the unclear man_made=communications_tower tag, nobody wrote
that she or he is opposed to deprecating it. Do we still need a
deprecation proposal? (Note that it wasn't introduced by a proposal.)

Regards
Markus

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

Re: [Tagging] mast / tower / communication_tower (again)

[SelfishSeahorse]

On Fri, 26 Oct 2018 at 01:58, Greg Troxel  wrote:
>
> This reliance on guys does not align with engineering reality.  guys are
> needed depending on forces/loading, and there can be unguyed masts, that
> are exactly like guyed masts but a bit shorter.

I agree.

> > A tower is a tall, slim free-standing structure, usually with internal
> > access. (Possible include from wiki: "Towers are specifically distinguished
> > from "buildings " in that they are
> > not built to be habitable but to serve other functions.")

Imho, the current definition of man_made=tower -- 'A tower is a
building, which is higher than it is wide' -- is nonsensical. A tower
can be a building (if it has walls and a roof) but it doesn't have to
be a building -- for instance, i wouldn't call an open lookout tower
[1] or the Eiffel Tower [2] buildings.

[1]: https://upload.wikimedia.org/wikipedia/commons/7/78/Gurtenturm.JPG
[2]: https://commons.wikimedia.org/wiki/File:Tour_Eiffel_Wikimedia_Commons.jpg

> For an example of something used in communications (an American thing,
> but totally normal and other countries surely have equivalent things
> with the same characteristics):
>
>   http://www.rohnnet.com/rohn-65g-tower
>
> which says right there can be up to 500 feet when guyed and 80 feet not
> guyed.  But it's the same thing in both cases -- it just needs more
> support when taller where the forces get bigger.

I'd call this is a -- either guyed or not guyed -- mast (because there
is no internal access).

> As I said earlier, things that are maybe 10cm in diameter are usually
> called masts.  These are very minor and not really used in
> telecom/broadcasting.

Do you call this [1] a mast in the USA?

[1]: https://commons.wikimedia.org/wiki/File:LeifersexTimZentrum.jpg

> So maybe we just need
>
>   man_made=antenna_support_structure
>
> for all things which are not buildings and basically exist to support
> antennas, and avoid the tower/mast word choice, which is pretty clearly
> contentious and/or confusing.

I'm not very convinced because that would mean that everything from
this tiny mast on a roof [1] to the Tokyo Tower [2] would be tagged
man_made=antenna_support_structure.

[2]: https://en.wikipedia.org/wiki/Tokyo_Tower

Regards

Markus

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

Re: [Tagging] mast / tower / communication_tower (again)

[SelfishSeahorse]

On Fri, 26 Oct 2018 at 08:23, Martin Koppenhoefer
 wrote:
>
> On the other hand, speaking about “numbers”, those are probably facts and not 
> protectable by copyright

If i'm not mistaken, numbers aren't protected by copyright, but a
compilation of numbers (i.e. a database) can be protected; if not by
copyright then by so-called database right. See:

https://www.esa.int/About_Us/Law_at_ESA/Intellectual_Property_Rights/Copyright_and_databases
https://en.wikipedia.org/wiki/Sui_generis_database_right

Regards

Markus

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

Re: [Tagging] 2 meaning for crossing=zebra

[SelfishSeahorse]

On Fri, 26 Oct 2018 at 12:37, marc marc  wrote:
>
> Le 26. 10. 18 à 09:28, SelfishSeahorse a écrit :
> > What about tagging the presence or absence of traffic signals with a
> > subkey, e.g. crossing:traffic_signals=yes/no?
>
> it is indeed always possible to take out all the values to make
> them keys.
> but if iD only enters the marking in crossing_ref like the other
> editors, the crossing key will again indicate whether or not there is a
> light. so is it useful to change the name of the key there too?

How would you tag the absence of traffic signals? crossing=no_traffic_signals?

And what about the absence of road markings? crossing_ref=unmarked?

> experience shows that if you want to change everything, in the end
> nothing changes because many contributors have started from immobility
> when the solution is too large. that is why I think it is useful to
> focus on how to correctly inform the type of ground marking

If we can solve the problem with less change that's fine too, but the
solution should be unambiguous and clear.

Regards

Markus

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

Re: [Tagging] 2 meaning for crossing=zebra

[SelfishSeahorse]

On Fri, 26 Oct 2018 at 16:17, Martin Koppenhoefer
 wrote:
>
> in Switzerland? In Italy they aren’t called zebra crossings (despite the 
> markings), they’re called traffic lights with pedestrian crossing. A zebra 
> crossing here means there aren’t traffic lights.

Yes, the (yellow) zebra crossings are called 'zebra stripes'
(Zebrastreifen) -- or officially 'pedestrian stripes'
(Fussgängerstreifen) -- independently if there are traffic lights or
not.

Regards

Markus

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

Re: [Tagging] 2 meaning for crossing=zebra

[SelfishSeahorse]

On Fri, 26 Oct 2018 at 16:14, Martin Koppenhoefer
 wrote:
>
>
>
> sent from a phone
>
> > On 26. Oct 2018, at 14:57, SelfishSeahorse  
> > wrote:
> >
> > And what about the absence of road markings? crossing_ref=unmarked?
>
>
> we generally do not map road markings, we don’t map the divider lines between 
> lanes, we don’t map diagonally striped areas where traffic can’t go, we don’t 
> map stop lines, we don’t map any road markings, why’s there so much focus on 
> the road markings in this thread?

Because road markings at crossings tell pedestrians if they have right
of way or not.

>
> The interesting information (IMHO) is whether there are traffic lights or 
> not, where the crossings without signals are and whether crossing pedestrians 
> take precedence over vehicles. The actual signs and markings for this are 
> kind of a sideshow for the traffic sign nerds, important to know for the 
> jurisdictions where you map, but nothing that must necessarily be explicitly 
> mapped. We are interested in the effects, aren’t we?

Agree.

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

Re: [Tagging] 2 meaning for crossing=zebra

[SelfishSeahorse]

On Fri, 26 Oct 2018 at 12:53, Jyri-Petteri Paloposki
 wrote:
>
> On 26.10.2018 10.44, SelfishSeahorse wrote:
> > There are some marked non-zebra crossings in Switzerland:
> >
> > https://www.mapillary.com/map/im/zMqUsiFYNMiJ3_kA4ODHSQ
> > https://www.mapillary.com/map/im/OVsXNBwnJXFIAobJxFjUlQ
> >
> > However, i'm unsure if vehicles have to stop there if pedestrians want
> > to cross. (Vehicles have to stop at the yellow 'zebra' crossings.)
>
> In Finland the marking in the first image is for an ”extension of a
> cycleway”, ie. a place for cyclists to cross the road. It's not meant
> for foot traffic and doesn't give cyclists precedence over traffic on
> the road, unlike a marked footway crossing.

There's a cycleway that ends about 50 m next to that road markings.
Maybe it has been painted at the wrong place. :-) (It's not uncommon
that road markings or signs are misplaced or illogical. My favourite
is this sign [1] places some metres in front of stairs.)

[1]: 
https://commons.wikimedia.org/wiki/File:CH-Hinweissignal-Sackgasse_mit_Ausnahmen.svg

>
> The second one would in Finland probably be used for marking the edges
> of a bump, also having no effect on the precedence of traffic modes.

Thanks for your explanations. Could be that the authorities intended
that car drivers slow down by pretending that there is a speed table
(kind of a visual speed table).

Regards

Markus

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

Re: [Tagging] 2 meaning for crossing=zebra

[SelfishSeahorse]

On Fri, 26 Oct 2018 at 12:46, Tom Pfeifer  wrote:
>
> Why should we invent a new subtagging scheme when we already have one with 
> crossing=* + crossing_ref=* ?

Because there are countries where pedestrian crossings with traffic
signals also have zebra markings and it's not obvious that
crossing=zebra excludes crossings with traffic signals (they are even
called zebra crossings too). Therefore these crossings often get
wrongly tagged crossing=zebra.

Besides, the meaning of crossing=uncontrolled is even less clear.

> On Fri, 26 Oct 2018 at 01:19, Bryan Housel  wrote:
>  > - `crossing=unmarked` which is labeled “Unmarked Crossing”
>
> Tagging "unmarked crossings" does not make sense for me. An unmarked crossing 
> is defined in OSM by a
> road and a footway sharing a node, there is no need for a tag here, as there 
> is nothing special.

The absence of a highway=crossing (and a crossing=*) tag on a node
shared by a road and a footway doesn't mean that there is an unmarked
crossing, it could also mean that the footway continues on the
sidewalk or that the pedestrian crossing hasn't been mapped yet.

Regards

Markus

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

Re: [Tagging] mast / tower / communication_tower (again)

[SelfishSeahorse]

On Sat, 27 Oct 2018 at 02:05, Warin <61sundow...@gmail.com> wrote:
>
> US law does not apply everywhere.

Yes, it doesn't. Besides the USA don't recognise database right;
apparently it's mainly used in the EU.

Regards
Markus

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

Re: [Tagging] Wastewater Plants

[SelfishSeahorse]

On Sun, 28 Oct 2018 at 02:07, Graeme Fitzpatrick  wrote:
>
> I would actually call them tanks rather than basins

Doesn't a tank need to be closed?

> When you look at storage_tanks 
> https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dstorage_tank, there are 
> actually sub-tags for
> content=sewage & content=wastewater, a so it would seem to be OK to use that?

Just because it's in use doesn't mean it makes sense, does it? See
landuse=basin.

> These could also be used with Clifford's possible wastewater= key?

You mean wastewater=clarifier|digester? I think so.

Regards
Markus

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

Re: [Tagging] Wastewater Plants

[SelfishSeahorse]

On Sun, 28 Oct 2018 at 08:14, Martin Koppenhoefer
 wrote:
>
> landuse for tagging features is not a good fit, I prefer man_made for these, 
> as it fits better with the general scheme of tags

I agree. This is why i proposed man_made=basin|tank in a later message.

Regards
Markus

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

Re: [Tagging] mast / tower / communication_tower (again)

[SelfishSeahorse]

On Fri, 26 Oct 2018 at 14:23, François Lacombe
 wrote:
>
> structure={lattice,guyed, tube...} would be better than tower:construction. 
> 15k uses vs 150k.
> Lattice is the structure and have nothing to do with actual construction. 
> This tag should be avoided.

Seems sensible.

> telecom=antenna would be a device, wile we are discussion of supports.
> It's the same for power=transformers (a device) supported by a power=pole (a 
> support). Using power=* for both support and device cause small issues 
> because power=* is used for the support.

If there are antennas attached to something else, e.g. mobile phone
and microwave relay antennas attached to an electricity pylon, [1] you
could simply add

communication:mobile_phone=yes
communication:microwave=yes

to

power=tower.

[1]: https://www.mapillary.com/map/im/eJ8dwz4EJ8hRSJPO1gRKEg

> telecom=antenna may be used to tag individual antennas on large towers too.

There's also man_made=antenna (with 6, 420 uses vs 167 uses of telecom=antenna):

https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dantenna

Regards
Markus

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

Re: [Tagging] mast / tower / communication_tower (again)

[SelfishSeahorse]

Hi Lionel

Thanks for this helpful clarification! I'd suggest to use them on OSM.

Regards
Markus

On Fri, 26 Oct 2018 at 11:30, Lionel Giard  wrote:
>
> At my work (a telecom company in Belgium), i see these types of mobile 
> structure construction :
> - Self-supported pylons (the "tower", mostly looking like the power=tower in 
> OSM, but also including the (older) self-supported tower in concrete) ;
> - Guy-wired pylons (the "mast" as described in the engineering definition 
> where it is a structure held by guys);
> - Self-supported roof structure (half of them are just simple antennas, the 
> other half are mast (the larger structure that clearly hold more than 1 
> antenna on top of buildings));
> - Guy-wired roof structure (all of them are mast);
> - And some other things like on electricity pylons(all of them are just 
> antennas on top of something as far as i know).
>
> And as a sub-type (indicating type of construction) : we got the "lattice 
> pylon", "tubular pylon", "lattice mast", "tubular mast" or just "tubes" (for 
> antennas isolated). So it would correspond to the 
> tower:construction=guyed_lattice or guyed_tube (for mast) and lattice or 
> freestanding (for the tower). Note that the older concrete telecom tower is 
> noted as "tubular pylon".
>
> Thus, as i see it, the tower tag is the equivalent of pylon (as in the 
> power=* tag where the power=tower is the equivalent of what we call 
> "electricity pylon" here) and the mast are either the guy-wired structures OR 
> the "largest" structures on the roof of buildings (which are clearly not an 
> unique antenna). And then we need a tag for isolated antenna (i saw that a 
> "telecom=antenna" was proposed on the telecom wiki page and i used it some 
> times, but that's just a tag to indicate either on a node (on top of a 
> building) or on another structure (like power=tower) that a telecom antenna 
> is there. So to me, this covers everything i see in our database.
>
> If we use the current definition, the only problem i see is for the 
> "self-supported pylons" which should all be tagged as tower (on engineering 
> terminology), but could currently be tagged as mast if they don't look like 
> "big tower". But the problem is minor, as if you look at the tag 
> "tower:construction", the "guyed_lattice" and "guyed_tube" already say that 
> it is a 'mast' in the engineering definition (and as far as i know, all masts 
> are either guyed_lattice or guyed_tube construction !). ;-)
>
> => And thus, the only change i would make is to the sub-tag 
> tower:construction : using "lattice" or "tube" for the "freestanding" towers 
> (the freestanding value is more general but give not much information as if 
> it is not guyed, i think it is always freestanding). So at the end, the 
> engineering definition is clearly indicated via this tag.
>
> Best regards,
> Lionel
>
> Le ven. 26 oct. 2018 à 09:07, Martin Koppenhoefer  a 
> écrit :
>>
>>
>>
>> sent from a phone
>>
>> On 26. Oct 2018, at 01:57, Greg Troxel  wrote:
>>
>> for all things which are not buildings and basically exist to support
>> antennas, and avoid the tower/mast word choice, which is pretty clearly
>> contentious and/or confusing.
>>
>>
>>
>> what about this: 
>> https://upload.wikimedia.org/wikipedia/commons/1/11/Killesberg_Tower.jpg
>>
>> Actual tagging is even more weird, or does anyone recognize a mansard roof 
>> here?
>> https://www.openstreetmap.org/way/306362151
>>
>> this is not a building, neither by the German nor by the English definition, 
>> but at least for Germans it is a tower.
>> I would not require for towers to be a building (which at a minimum should 
>> provide some enclosed space).
>>
>>
>> Cheers, Martin
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Area with restaurants, hotels, cinemas - is it landuse=commercial?

[SelfishSeahorse]

I'm not very happy with our definition of landuse=commercial as it
isn't self-explanatory: it is mainly used for offices and warehouses,
while retail, although belonging to commerce, has its own landuse=*
value. In my opinion, it would make more sense either to tag retail as
landuse=commercial + commercial=retail or to tag different commercial
land uses with separate landuse=* values, e.g. landuse=offices,
landuse=wholesale or landuse=storage.

Concerning restaurants, hotels and cinemas:

- Restaurants are more similar to shops than to offices or
warehouses (what landuse=commercial is mainly used for), so i think
landuse=retails is ok.

- Hotels are more about services than sale, so i wouldn't use
landuse=retail for them. Maybe landuse=residential?

- Cinemas: What about landuse=leisure?

Regards

Markus

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

Re: [Tagging] Feature Proposal - RFC - landuse=governmental

[SelfishSeahorse]

On Wed, 31 Oct 2018 at 12:00, Martin Koppenhoefer
 wrote:
>
> WRT to Joseph's comment about "municipal, statal and federal", I would 
> welcome adding a property for the level (if a generic level is chosen for 
> landuse), maybe "admin_level" would suit best?

This seems like a good idea.

> How will we deal with uses shared by bodies of different levels in the 
> hierarchy, e.g. a site which is used together by federal and state entities 
> (e.g. on different building levels, or in cooperation).

I think it should be save to add all admin_level's separated by semicolons.

Regards
Markus

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

Re: [Tagging] Feature Proposal - RFC - (consulate)

[SelfishSeahorse]

On Thu, 1 Nov 2018 at 09:41, Martin Koppenhoefer  wrote:
>
> > I haven't seen anyone (recently) who supports your original proposal of 
> > keeping amenity=embassy and adding amenity=consulate. So I believe your 
> > first summary is inaccurate.
>
> I do. For me this is most consistent with the rest of the system, requires 
> the least modifications and I don’t see why it shouldn’t work.

+1

Regards
Markus

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

Re: [Tagging] 2 meaning for crossing=zebra

[SelfishSeahorse]

On Fri, 26 Oct 2018 at 15:29, Bryan Housel  wrote:
>
> `crossing=marked` and `crossing=unmarked` are not new.  They’ve been in use 
> for years.
>
> They solve the problem in that they are unambiguous and beginner-friendly.

Unfortunately crossing=marked doesn't make a difference compared to
crossing=zebra. It's still not possible to tag a marked (zebra)
crossing with traffic signals (except from
crossing=marked;traffic_signals, which data users possibly can't
handle).

And if it's intended that crossing=marked excludes marked crossings
with traffic signals, it isn't unambiguous any more.

Regards

Markus

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

Re: [Tagging] 2 meaning for crossing=zebra

[SelfishSeahorse]

On Fri, 26 Oct 2018 at 17:09, Martin Koppenhoefer
 wrote:
>
> On 26. Oct 2018, at 16:39, SelfishSeahorse  wrote:
> >
> > Yes, the (yellow) zebra crossings are called 'zebra stripes'
> > (Zebrastreifen) -- or officially 'pedestrian stripes'
> > (Fussgängerstreifen) -- independently if there are traffic lights or
> > not.
>
>
> is a sign required in switzerland [...]

In rural areas a sign [1] is required, in built-up areas it is only
required if the crossing is badly visible.

[1]: 
https://commons.wikimedia.org/wiki/File:CH-Hinweissignal-Standort_eines_Fussgängerstreifens.svg

> [...] and do pedestrian take precedence?

Without traffic lights, pedestrians have always the right of way. With
traffic lights, pedestrians only have right of way when the light is
green.

> Are there additional signs at traffic lights?

No.

Regards
Markus

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

Re: [Tagging] 2 meaning for crossing=zebra

[SelfishSeahorse]

On Fri, 26 Oct 2018 at 17:13, Martin Koppenhoefer
 wrote:
>
> > On 26. Oct 2018, at 16:39, SelfishSeahorse  
> > wrote:
> >
> > Because road markings at crossings tell pedestrians if they have right
> > of way or not.
>
> it depends on the jurisdiction which kind of markings have which implications 
> or meanings. We’re mostly interested in collecting a model of the meanings, 
> the physical representations are more a kind of source for this information. 
> Nice as an addon, but not essential for the model (but also not useless).

That's true and i agree, but how would you name a tag of a pedestrian
crossing where pedestrians have right of way (and that doesn't have
traffic lights) crossing=pedestrian_right_of_way?

It seems easier to tag what's visible on the ground.

Regards
Markus

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

Re: [Tagging] Feature Proposal - RFC - landuse=governmental

[SelfishSeahorse]

On Sun, 14 Oct 2018 at 04:02, Joseph Eisenberg
 wrote:
>
> However, I'm not sure that "governmental" is the best value for the landuse 
> key. I think there would be a risk of mappers finding this tag in the editors 
> and using it for all governnment-owned land, not just for administrative 
> offices. In North America, and in many developing countries, the national or 
> local government owns large areas of land, including rangeland, forests, 
> transportation facilities, and military areas, in addition to land uses for 
> government offices.
>
> In North America, it is somewhat common to talk about "government land" or 
> more specifically, "Federal land," "State land", and "Municipal land". But 
> the only uses of "governmental land use" I've found are in phrases talking 
> about "governmental land use policy", "governmental land use regulations", 
> and "governmental land use decision making". In these cases, the phrase is 
> talking about governments regulating all types of land use, including 
> commercial, retail, residential and industrial.

I think if editors will name the landuse=governmental preset
'government premises', there won't be a high risk that people would
use this tag for land owned or regulated by the government.
Alternatively, renaming the tag landuse=government_premises (or
landuse=governmental_site) should clear up any ambiguities.

Regards
Markus

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

Re: [Tagging] Wastewater Plants

[SelfishSeahorse]

On Fri, 26 Oct 2018 at 19:23, Clifford Snow  wrote:
>
> For tagging, I'd to suggest the two tags.
> man_made=clarifier (used 28 times)
> man_made=digester (anaerobic used 3 times, including one misspelling)

Another idea i see is to extend the current tagging scheme with
landuse=basin (+ content=sewage) by creating new basin=* values
basin=clarifier and basin=digester. This would have the advantage that
no retagging is required and people that want to map the basins but
don't know their function can still map them.

Regards
Markus

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

Re: [Tagging] Wastewater Plants

[SelfishSeahorse]

On Sat, 27 Oct 2018 at 15:06, Paul Allen  wrote:
>
> It has the disadvantage that it doesn't make sense.  At least not to me, as a 
> native speaker of
> British English (which is the normal language for defining OSM tags) and as 
> somebody who
> doesn't work in sanitation.  Maybe a British sanitation engineer would use 
> basin or a non-British
> speaker would use basin but I most definitely would not.
>
> Firstly, I don't think of a settling tank or clarifier as a basin.  A 
> porcelain object for washing hands
> in a bathroom is a basin and a geological depression in which water collects 
> is a basin, and a
> man-made depression for holding water might be a basin but a clarifier isn't. 
>  I can see the
> commonalities in all of those but a clarifier just isn't a basin.  Other than 
> bathroom porcelain,
> a basin requires a depression in the ground.

Sorry, my mistake, i didn't think of tanks. The wastewater plants i've
mapped so far have concrete lined depressions like those on these
images:

https://commons.wikimedia.org/wiki/File:Flug_Leer_nach_Emden_2010_11.JPG
https://commons.wikimedia.org/wiki/File:Kläranlage_Heidelberg_Grenzhof.JPG
https://commons.wikimedia.org/wiki/File:090913-EpurationOupeye_0020.jpeg
https://commons.wikimedia.org/wiki/File:Sedimentation_tank.jpg

I think it's okay to call them basins, isn't it?

> Secondly, if you're going to apply landuse to a man-mad object rather than to 
> an area of ground
> that holds a collection of man-made objects then instead of building=house we 
> should have
> landuse=house.  We don't do things that way.

You're right, basins aren't land uses.

What about man_made=basin and man_made=tank then? (I know that there
is man_made=storage_tank, but these tanks are for treating waste
water, not for storing them.) These tags could also be used for basins
and tanks that serve other purposes, for example slurry basins or
tanks.

Regards
Markus

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

Re: [Tagging] Feature Proposal - RFC - landuse=governmental

[SelfishSeahorse]

Hello!

I've made following additions to the proposal:

* Addition of the new tag
governmental=legislature/executive/judiciary for specifying the
governmental branch.
* Reuse of the existing tag admin_level=* for indicating the
administrative level (country, state, municipal etc.).

Are there any more comments on the proposal? Otherwise i'd like to start voting.

Have a nice day!
Markus

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

Re: [Tagging] Feature Proposal - RFC - landuse=governmental

[SelfishSeahorse]

Hi Mateusz,

Thank you for your feedback!

> "for marking government premises" sounds like replacement of office=* tag

I've changed the definition (back) to 'land used by government bodies
/ for governing'.

> Current definitions "This excludes: (...) Land ''owned'' by the government" 
> means that
> parliament complex owned by government is not landuse=government.

I've changed this to:

'Land owned by the government, but not used for governing'

Hope it's clearer now.

Regards
Markus

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

Re: [Tagging] Feature Proposal - RFC - Tramtrack on highway

[SelfishSeahorse]

On Friday, November 2, 2018, Martin Koppenhoefer 
wrote:

>
> Frequently you can't get this right. You will often have just one
> carriageway (i.e. one highway way) and you will usually have 2 ways for the
> tram tracks (if you draw each of them).
>

Although less precise, i would have only drawn one and tagged it tracks=2
in order to not break topology. I don't understand why traffic lanes
(tagged on street way) and tram tracks (mapped with separate ways) are
treated differently, although both are part of the same street.

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

Re: [Tagging] Feature Proposal - RFC - Tramtrack on highway

[SelfishSeahorse]

Anyway, i'm wondering why tram tracks that are embedded in a street are
mapped with separate ways instead of reusing the street way? Separating
them seems topologically wrong.

For example at this pedestrian crossing [1] one doesn't first cross tram
tracks, then the street and then again tram tracks, but a street with
embedded tracks in its mid. Or driving westwards on Schlossstrasse and
turnung into Friedbühlweg at the nearby crossroads [2], one doesn't cross
any tram tracks.

[1]: https://www.openstreetmap.org/way/545874049
[2]: https://www.openstreetmap.org/node/696678395

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

Re: [Tagging] 2 meaning for crossing=zebra

[SelfishSeahorse]

On Fri, 26 Oct 2018 at 00:02, Martin Koppenhoefer
 wrote:
>
> I agree that in areas where marked pedestrian crossings aren’t marked as 
> zebra crossings, the tag could create problems or could not apply (I do not 
> know about such places but someone wrote it in the wiki).

There are some marked non-zebra crossings in Switzerland:

https://www.mapillary.com/map/im/zMqUsiFYNMiJ3_kA4ODHSQ
https://www.mapillary.com/map/im/OVsXNBwnJXFIAobJxFjUlQ

However, i'm unsure if vehicles have to stop there if pedestrians want
to cross. (Vehicles have to stop at the yellow 'zebra' crossings.)

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

Re: [Tagging] 2 meaning for crossing=zebra

[SelfishSeahorse]

On Fri, 26 Oct 2018 at 01:19, Bryan Housel  wrote:
>
> Oh!  I don’t like `crossing=zebra` either.  Not sure whether you caught the 
> end of that issue #4788, but anyway I've decided I'm tired of hearing people 
> complain about `crossing=zebra` so going forward iD will support these 2 
> presets:
>
> - `crossing=marked` which is labeled “Marked Crosswalk"
> - `crossing=unmarked` which is labeled “Unmarked Crossing”

If crossing=marked would exclude marked crossings with traffic
signals, that wouldn't solve the problem that Marc and i often come
across. If people see a marked crossing on the aerial imagery, they
would tag it crossing=marked, which would imply that this crossing
doesn't have traffic signals.

The problem with the crossing=* key is that it combines several
incompatible concepts, that is the presence or absence of traffic
signals, of road markings and of islands. It seems that the only
solution to this problem is moving all these properties to dedicated
subkeys, that is:

crossing:traffic_signals=yes/no
crossing:marked=yes/no
crossing:island=yes/no

Regards
Markus

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

Re: [Tagging] 2 meaning for crossing=zebra

[SelfishSeahorse]

On Thu, 25 Oct 2018 at 23:40, marc marc  wrote:
>
> Hello,
>
> I have a big issue with crossing=zebra.
> it prevent to fill in the other value for crossing like
> crossing=traffic_signals crossing=uncontrolled
> the wiki [1] said that crossing=zebra is a shortchut for
> crossing=uncontrolled + crossing_ref=zebra in the UK
> but a lot of zebra also in UK and outside UK have traffic_signals
> and must be tagged with crossing=traffic_signals
> so at the end, crossing=zebra has no meaning... maybe the previous
> contributor mean crossing=uncontrolled + crossing_ref=zebra
> but maybe he mean only crossing_ref=zebra
> I fix a few week a lot of crossing=zebra crossing_1=traffic_signals
> or crossing=zebra;traffic_signals that show it's an issue.

What about tagging the presence or absence of traffic signals with a
subkey, e.g. crossing:traffic_signals=yes/no?

I've already proposed to replace crossing=island with
crossing:island=yes [1] for the same reason, that is, because when
using crossing=island, it's not possible to specify if the pedestrian
crossing is marked or not.

[1]: https://wiki.openstreetmap.org/wiki/Proposed_features/Key:crossing:island

Regards
Markus

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

Re: [Tagging] 2 meaning for crossing=zebra

[SelfishSeahorse]

On Fri, 26 Oct 2018 at 11:30, Mateusz Konieczny  wrote:
>
> Tagging way crossing=traffic_island and nodes crossing=traffic_signals is
> deeply not obvious.

+1. That's too complicated. Furthermore it doesn't work on
one-carriageway roads like e.g. here:

https://www.openstreetmap.org/node/893451214

Regards
Markus

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

Re: [Tagging] 2 meaning for crossing=zebra

[SelfishSeahorse]

On Fri, 26 Oct 2018 at 11:12, Mateusz Konieczny  wrote:
>
> Yes. For example in Poland there are crossing markings that look
> very similar and have the same name with different legal
> implications.

Is there more than one marked crossings type w/o traffic signals in
Poland? That is, one where pedestrians have right of way and another
where vehicles have right of way?

Regards
Markus

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

Re: [Tagging] Wastewater Plants

[SelfishSeahorse]

On Sun, 28 Oct 2018 at 23:30, marc marc  wrote:
>
> man_made=tank + usage=clarifier or usage=digester

+1

Regards
Markus

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

Re: [Tagging] 2 meaning for crossing=zebra

[SelfishSeahorse]

On Sat, 27 Oct 2018 at 21:24, bkil  wrote:
>
> crossing=uncontrolled had just this meaning - not controlled or
> arranged by any device but instead always negotiated in situ between
> traffic participants. [...]
>
> It should definitely not be understood as a synonym for "unmarked".
> I'll try to clarify this one on the wiki.
>
> The top web search result also confirms this interpretation of "uncontrolled":
>
> http://www.apwa-mn.org/userfiles/ckfiles/files/SafetyConsiderationsUncontrolledPedestrianCrossings.pdf

Quoting from this document:

'Safety Effects of Marked Versus Unmarked Crossings at Uncontrolled
Locations / At uncontrolled pedestrian crossing locations, installing
marked crosswalks should not be regarded as a magic cure for
pedestrian safety problems.'

An uncontrolled crossing just means a crossing without traffic lights,
thus, it can also be an unmarked crossing.

Regards
Markus

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

Re: [Tagging] mast / tower / communication_tower (again)

[SelfishSeahorse]

On Thu, 25 Oct 2018 at 00:04, Graeme Fitzpatrick  wrote:
>
> Do we also need a RFC / vote to amend the wiki page, or can I just amend it & 
> clear up the bad reference photo's?
>
> I'd be looking at combining the mentioned engineering definition with the 
> popular opinion expressed here to become:
>
> A mast is a tall, slim structure supported by guys, usually with external 
> access only

According to this definition, short (< 10 m) antennae 'poles' on
buildings [1] were 'towers' and thus would be tagged the same as
towers more than 100 m high [2].

[1]: https://commons.wikimedia.org/wiki/File:LeifersexTimZentrum.jpg
[2]: https://commons.wikimedia.org/wiki/File:Zuerich_Uetliberg_Sendeturm.jpg

As i've written in my previous message, guy-wires are used to
stabilise tall masts. Therefore the absence of guy-wires doesn't imply
that it's a tower.

I'd leave the current definition as is, just adding that usually tall
masts are guyed but towers aren't.

> A tower is a tall, slim free-standing structure, usually with internal 
> access. (Possible include from wiki: "Towers are specifically distinguished 
> from "buildings" in that they are not built to be habitable but to serve 
> other functions.")

Cooling towers or defensive towers aren't slim, but are still towers.
And garages or office buildings aren't built to be habitable, but are
still buildings. (I think it's fine to call a tower a building if it's
closed, that is, has walls and a roof.)

> Replacing man_made=communications_tower with man-made=tower; 
> tower=multi_purpose. Yes they're used for communication in that they have 
> antennae mounted on them, but are also usually tourist spots with lookouts & 
> so on, where normal TV towers etc aren't.

Imho, multi purpose is too broad. Note that, for example, there are
also bell towers with antennae inside. I think it would be best to
either tag all purposes (e.g. tower:type=communication;observation) --
which, however, might be problematic for data users -- or to tag the
main purpose only.

Regards
Markus

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

Re: [Tagging] mast / tower / communication_tower (again)

[SelfishSeahorse]

On Thu, 25 Oct 2018 at 07:45, Graeme Fitzpatrick  wrote:
>
> A lot of the big ones will be listed somewhere on the internet - the really 
> big ones have their heights listed on that wiki page I mentioned earlier

Just note that Wikipedia (and other websites) isn't a legal source for
OSM because of its incompatible license:

https://wiki.openstreetmap.org/wiki/Collaboration_with_Wikipedia

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

Re: [Tagging] Feature Proposal - RFC - Tramtrack on highway

[SelfishSeahorse]

On Wed, 7 Nov 2018 at 03:45, Paul Johnson  wrote:
>
> Putting the centerline of the rails somewhere other than the middle of the 
> tracks is arguably worse, particularly for use cases that depend on this 
> (creating a train simulator, or pedestrian navigation, for example).

As far as pedestrian navigation is concerned, it depends on whether
sidewalks are mapped as separate ways or as tags on the road. In the
latter case, a pedestrian router doesn't know that there are tram
tracks on the road, but that there are tram tracks *next to* (outside)
the road.

Consider the following crossing and imagine that the northern sidewalk
of Schlossstrasse wasn't mapped as a separate way, but as sidewalk=*
on the road way:

https://www.openstreetmap.org/node/721154448

When turning from the northern sidewalk of Schlossstrasse into
Mutacherstrasse, a pedestrian router would assume that one has to
cross tram tracks (which obviously isn't the case). Even for vehicles
driving on westwards on Schlossstrasse and turning into
Mutacherstrasse a router would assume that the vehicle has to cross
tram tracks (although in reality the tram tracks are located in the
middle of the road and the traffic lane further away).

Regards
Markus

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

Re: [Tagging] Feature Proposal - RFC - Tramtrack on highway

[SelfishSeahorse]

On Wed, 7 Nov 2018 at 23:17, Paul Johnson  wrote:
>
> Moot point, sidewalks should be mapped as separate ways for the same reason.

I don't want to start another sidewalk discussion, but please note
that sidewalks as separate ways don't solve all problems. Especially
in residential areas without marked pedestrian crossings or lowered
kerbs, connecting sidewalks to streets (in order to prevent islands)
is arbitrary.

Besides, the second problem i described (position of traffic lanes
relative to tram tracks) would still be unsolved.

Regards
Markus

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

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

[SelfishSeahorse]

On Tue, 13 Nov 2018 at 01:52, Eugene Alvin Villar  wrote:
>
> My thinking on this is we should re-purpose the relation roles for this sort 
> of tagging. Right now we just copy the roles from type=multipolygon relations 
> (inner, outer) when we should be using something like the following:
>
> Hypothetical but real-life example:
> Country A and Country B are disputing Territory C but currently Country A 
> controls it.
> - The borders (ways) between A and B that are not in dispute should be tagged 
> with role=de_jure in both countries' boundary relations
> - The line of control (so the border between B and C) should be tagged with 
> role=de_facto in both countries' boundary relations.
> - The claimed border of B (so the "border" between A and C) should be tagged 
> with role=claimed in Country B's relation.
>
> So if you want to draw borders as we currently draw them in OSM, just pick-up 
> the de_jure and de_facto role ways in the relations to build up the boundary 
> polygons.
>
> But if you're from Country B and you want your claimed borders, just pick-up 
> the de_jure and claimed role ways in the relations to build up Country B's 
> boundary polygon.
>
> The point is, "inner" and "outer" are really superfluous and can be inferred 
> from the geometry itself. So we should be using the relation role to tag 
> these sorts of things. And we can even use it to tag even more complicated 
> situations like if Territory C is split in control between A and B.
>
> I am open to alternatives to my suggested role names, by the way ("de_jure", 
> "de_facto", "claimed").

I like your idea with 'de_jure', 'de_facto' and 'claimed' roles.
However, i see the following problems:

1. 'inner' roles (and thus 'outer' roles too) are still needed in
case a country has enclaves.
2. The boundary polygon would still not hold the information which
territory is undisputed and which is disputed. You still only have an
area that includes undisputed and disputed territory.

A possible solution i see would be:

1. A new boundary:part relation (with inner and outer roles) that
only includes either the undisputed or disputed area of a country.
2. Changing the definition of the current boundary relation in a
way that these boundary:part relations (areas) can be added as members
with role 'undisputed', 'controlled' or 'claimed' to the boundary
relation.

Thus, your example above (Country A and Country B are disputing
Territory C but currently Country A controls it) would be tagged as
follows:

1. A type=boundary:part relation with the area of country A
without the disputed territory C.
2. A type=boundary:part relation with the area of country B
without the disputed territory C.
3. A type=boundary:part relation with the disputed territory C.
4. A type=boundary relation for country A with 1 as member with
role 'undisputed' and 3 as member with role 'controlled'.
5. A type=boundary relation for country B with 2 as member with
role 'undisputed' and 3 as member with role 'claimed'.

Regards
Markus

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

Re: [Tagging] mast / tower / communication_tower (again)

[SelfishSeahorse]

Hi

On Sat, 29 Sep 2018 at 00:29, Michael Booth  wrote:
>
> The Wiki definition is: "a huge tower for transmitting radio applications 
> It is often made from concrete and usually a far visible landmark." 
> https://wiki.openstreetmap.org/wiki/Tag:man%20made=communications%20tower
>
> Looking at examples of this tag in OSM I would guess that out of the <4,000 
> objects worldwide most of them do not conform to that definition. Many of 
> them are small mobile phone/cell site "masts", towers less than 100m, or very 
> tall guyed masts.

I fail to understand the difference between a
man_made=communications_tower and man_made=tower +
tower:type=communication. Aren't all towers far visible landmarks?
When is a tower huge? The wiki page also says that 'another indication
is, that a man_made=communications_tower has stairs and a lift inside,
whereas as man_made=tower, tower:type=communication has to be climbed
on the outside.' However this is contradictory with the definition of
man_made=tower: 'a tower is accessible and provides platforms, whereas
a mast only offers ladder steps to climb it.'

It might be better to discourage man_made=communications_tower and tag
them man_made=tower + tower:type=communication + height=*.

> I'd like to retag the structures near me to something more suitable - however 
> the wiki pages aren't very clear in distinguishing between the various 
> constructions and sizes for masts and towers.

I'm not an expert on this, but i think the distinction steps/lift
inside (= tower) vs latter outside (= mast) makes sense.

> Hopefully people can agree that the following should be tagged as 
> man_made=mast or tower + tower:type=communication + tower:construction + 
> height? Using TV transmitters in the UK as examples:
>
> * mast - guyed lattice, 306m: 
> https://en.wikipedia.org/wiki/Durris_transmitting_station
> * mast - guyed tube, 351m: 
> https://en.wikipedia.org/wiki/Belmont_transmitting_station
> * tower - lattice, 219m: 
> https://en.wikipedia.org/wiki/Crystal_Palace_transmitting_station
> * tower - freestanding, 330m: 
> https://en.wikipedia.org/wiki/Emley_Moor_transmitting_station

I would have tagged them the same.

> But how should these examples be tagged in OSM? All of them are 
> self-supporting structures, so in engineering terms they are not masts.
>
> 1. https://binged.it/2xILZO9
> 2. https://www.geograph.org.uk/photo/2361955
> 3. https://www.geograph.org.uk/photo/2337468
> 4. https://en.wikipedia.org/wiki/Charwelton_BT_Tower
> 5. https://www.geograph.org.uk/photo/2053885
> 6. https://binged.it/2xTxcQK
> 7. https://fr.wikipedia.org/wiki/Tour_hertzienne_de_Villeneuve-d%27Ascq
> 8. https://www.geograph.org.uk/photo/2162874

Why aren't 2, 3, 5, 6 and 8 masts and 4 and 7 towers? Because the
structure itself is an antenna?

By the way, i'm wondering if poles with mounted antennas like in the
following image can also be called masts or if man_made=pole
(undocumented, but 2 047 uses so far) would be better?

https://wiki.openstreetmap.org/wiki/File:Mobilfunkmasten_auf_Wohnhaus_Gotzingerplatz_Muenchen.JPG

Regards
Markus

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

[Tagging] Dispensing vs vending (Was: Combined waste/recycling bins)

[SelfishSeahorse]

On Wed, 10 Oct 2018 at 00:50, Martin Koppenhoefer
 wrote:
>
> > On 9. Oct 2018, at 21:19, bkil  wrote:
> >
> > amenity=waste_basket
> > waste=dog_excrement
> > vending=excrement_bags
> >
> > I've also seen waste_basket:excrement_bags=yes and fee=no, but I don't
> > see much value in these at this point in time.
>
> while vending=* with fee=no is some kind of open contradiction, without the 
> fee tag the contradiction is implicitly still there in many instances.
>
> Shouldn’t that better be „dispensing“ rather than vending?

I've used dispensing:excrement_bags=yes several times, in combination
with either amenity=dispenser (example [1]) or amenity=waste_basket
(example [2]).

[1]: https://commons.wikimedia.org/wiki/File:Cézy-FR-89-toutounet-01.jpg
[2]: https://commons.wikimedia.org/wiki/File:Dogs_excrements_A.jpg

Now that i checked Taginfo, these tags have all gone away, obviously
been 'corrected' -- very annoying ...

https://images.says.com/uploads/story_source/source_image/405030/1ae1.png

Markus

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

Re: [Tagging] Combined waste/recycling bins

[SelfishSeahorse]

On Tue, 9 Oct 2018 at 16:32, Paul Allen  wrote:
>
> A village a few miles from me (but in a different county) recently got one of
> these combined litter/recycling bins:
> https://www.facebook.com/permalink.php?story_fbid=2241627292737699=1632021387031629&__tn__=C-R
>
> How to tag?

What about

amenity=waste_basket
recycling:cans=yes
recycling:paper=yes
recycling:plastic=yes

?

Regards
Markus

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

Re: [Tagging] Combined waste/recycling bins

[SelfishSeahorse]

On Wed, 10 Oct 2018 at 19:46, Paul Allen  wrote:
>
> If I do it as one node or a single area, that is about the best that can be 
> done with existing
> tags.  The problem is it will get the icon for a waste bin, with no 
> indication it's also for
> recycling.  Fine if you use the query tool, but not many people would do that.

That's true.

> If I tag it as adjacent nodes or areas it's unlikely (with current tile-based 
> rendering) to display
> both icons, and it's not possible to guarantee which one will show up.

It would be nice if openstreetmap-carto would offer more zoom (at
least zoom level 20). There are also bus stops hidden by shelters or
shops hidden by other shops ...

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

Re: [Tagging] simply documenting tags WAS Re: hydrants

[SelfishSeahorse]

On Wed, 10 Oct 2018 at 09:39, Martin Koppenhoefer
 wrote:
>
> Map feature pages are for the documentation of established tags, I hope we 
> can agree on this?
>
> IMHO we should clarify that documenting ad hoc tags in the wiki (link above) 
> means either putting this documentation in your user space of the wiki, or in 
> the proposal space.

+1

Markus

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

Re: [Tagging] mast / tower / communication_tower (again)

[SelfishSeahorse]

On Sun, 30 Sep 2018 at 14:45, Martin Koppenhoefer
 wrote:
>
> > To solve the contradiction we need to get rid of one of the two definitions.
>
> they could be combined: if it is intended to be accessed by people (not only 
> for maintenance) and is not guyed it is a tower, otherwise it would be a mast.

I think it's better to stick to either a common or a technical
definition. OSM-specific definitions are prone to create confusion and
tagging mistakes.

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

Re: [Tagging] mast / tower / communication_tower (again)

[SelfishSeahorse]

On Sun, 30 Sep 2018 at 03:13, Graeme Fitzpatrick  wrote:
>
> https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dmast says that
>
> "In structural engineering, mast is a vertical structure, supported by 
> external guys and anchors.
>
> This is the only existing definite feature that could be used to 
> differentiate masts and towers."
>
> but then shows an photo example of a "mast" with no guys.

Thanks for pointing to that definition -- i wasn't aware of it. The
confusion on the wiki seems to come from the fact that 'the terms
"mast" and "tower" are often used interchangeably', as noted on
Wikipedia:

https://en.wikipedia.org/wiki/Radio_masts_and_towers#Mast_or_tower?

That is, we have two contradictory definitions on the wiki: the
engineering definition according to which a tower is freestanding and
mast guyed, and the other definition according to which 'a tower is
accessible and provides platforms, whereas a mast only offers ladder
steps to climb it'. (Where does this latter definition come from?)

To solve the contradiction we need to get rid of one of the two definitions.

Regards
Markus

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

Re: [Tagging] motorcar definition changed recently

[SelfishSeahorse]

On Wed, 3 Oct 2018 at 11:33, Martin Koppenhoefer  wrote:
>
> I have tried to fix the picture and found, that there are now 2 distinct 
> traffic signs, one is for all 2-tracked motor vehicles, including cars:
> https://en.wikipedia.org/wiki/Road_signs_in_Germany#/media/File:Zeichen_251_-_Verbot_für_Kraftwagen_und_sonstige_mehrspurige_Kraftfahrzeuge,_StVO_1992.svg
>
> The other is explicitly for motorcars (those for the transport of up to 8 
> people, including the driver):
> https://en.wikipedia.org/wiki/Road_signs_in_Germany#/media/File:Zeichen_257-55_-_Verbot_f%C3%BCr_Personenkraftwagen,_StVO_2017.svg

臘

Is anyone aware of other countries where these two traffic signs with
their different meanings are in use?

> How are we going to distinguish these?

We probably cannot avoid defining two new keys, for example car=* and
double_tracked_motor_vehicle=*, and discouraging motorcar=* because of
its ambiguity ¬(motorcar=yes) ≠ (motorcar=no). Then, motorcar=yes can
be converted to car=yes and motorcar=no to
double_tracked_motor_vehicle=no.

In the meantime, i advise everyone to tag 'no entry for any power
driven vehicle except two-wheeled motor cycles without side-car' signs
unambiguously motor_vehicle=no + motorcycle=yes (+ moped=yes/mofa=yes
if not counted as motorcycle).

Regards
Markus

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

Re: [Tagging] motorcar definition changed recently

[SelfishSeahorse]

On Mon, 3 Sep 2018 at 17:58, Martin Koppenhoefer  wrote:
>
> Thank you, I have now reverted the change wrt to motorcar.

I've also reverted the change on the page
https://wiki.openstreetmap.org/wiki/Key:motorcar and tried to make the
different meanings of that tag when either used as permission or
restriction clearer.

Regards
Markus

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

Re: [Tagging] Ignore roundabout flare in counting

[SelfishSeahorse]

On Sat, 6 Oct 2018 at 09:12, Florian Lohoff  wrote:
>
> On Fri, Oct 05, 2018 at 10:46:08PM +0200, SelfishSeahorse wrote:
> > On Friday, October 5, 2018, Florian Lohoff  wrote:
> > > Is there tagging to let announcements ignore that flare?
> >
> > I think that if the driveway is tagged highway=service, this should be
> > enough information for the routeing engine to ignore it. Besides there
> > might be people that don't want the driveway to be ignored.
>
> What about roundabouts only with services? Private property, military,
> industrial complexes? No voice guidance there?

The voice guidance could tell you to take the xth service exit.

Or in your example [1] if you come from SW on Groppeler Straße and
want to go into the driveway, it could announce: 'take the service
exit next to the 2nd exit' or 'drive into the driveway next to the 2nd
exit'.

[1]: https://www.openstreetmap.org/#map=18/51.90770/8.26519

Apparently, OSMR already skips service roads when counting roundabout
exits. In that example, travelling from SW to NW, it says: 'At
roundabout take 3rd exit onto Tecklenburger Weg'. However, when
travelling from SW into the driveway, it also counts the driveway as
3rd exit: 'At roundabout take 3rd exit onto unnamed road'. This could
be optimised.

> I rather go for an explicit tagging to exclude flares in counting as
> long as you dont enter or leave the roundabout at that road.

In my opinion all the information for the routing engines is already
there -- i don't know how this should be tagged differently.

Regards
Markus

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

Re: [Tagging] How to tag named group of named water areas?

[SelfishSeahorse]

On Mon, 8 Oct 2018 at 13:55, SelfishSeahorse  wrote:
>
> On Mon, 8 Oct 2018 at 13:13, Martin Koppenhoefer  
> wrote:
> >
> > A very similar problem are parts of lakes by the way, e.g. look at this map 
> > of the lake of Constance, showing names for parts of the lake: 
> > https://de.wikipedia.org/wiki/Bodensee#/media/File:Bodensee_satellit%2Btext.png
> > (or maybe the "lake" in this case is a group of lakes as well).
>
> This problem could be solved with *:part=* areas (in this example
> natural:part=lake), analogous to building:part=*.

PS: Sorry, i meant natural:part=water (+ water=lake).

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

Re: [Tagging] landuse for government offices ?

[SelfishSeahorse]

Hello everyone!

I haven't forgotten the landuse=civic_admin proposal, but I'm
uncertain about two points and would like to know your opinion:

* Isn't 'civic administration' limited to the administration of a town
or city (compared to the administration of the state, county etc.)?
Maybe it would be better to use landuse=public_administration (24
uses) or simply landuse=government (162 uses) instead. (For
comparison: landuse=civic_admin also has 162 uses.)
* Currently the proposal only includes areas of legislative, executive
and governmental administration use, but excludes courts. Wouldn't it
make sense to also include courts? People who want to distinguish
administration, legislature, executive and judiciary could do this
with a sub-tag, e.g. government=*.

Regards
Markus

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

Re: [Tagging] motorcar definition changed recently

[SelfishSeahorse]

The meaning of the motorcar key has been discussed some time ago with the
conclusion that motorcar=no means 'no entry for any power driven vehicle
except two-wheeled motor cycles without side-car', while motorcar=yes only
means that motorcars are allowed. (Unfortunately i couldn't find the
discussion yet.)

So yes, i think the change should be reverted.

Regards
Markus

On Sun, 2 Sep 2018 23:14 Martin Koppenhoefer, 
wrote:

> OMG the Germans have overtaken the wiki. I just noticed this change to the
> motorcar access definition:
>
> https://wiki.openstreetmap.org/w/index.php?title=Key%3Aaccess=revision=1601167=1598869
>
>
> https://wiki.openstreetmap.org/w/index.php?title=Key:motorcar=next=1532406
>
>
> I used motorcar to mean automobile in the past, although most of the time
> the restrictions were more general. motorcar=no meant probably also hgv=no,
> but in access=no & motorcar=yes I don’t think that hgv=yes is implied.
>
> Cheers,
> Martin
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] wiki modification landuse=meadow definition

[SelfishSeahorse]

I remember it has been discussed, but maybe not on this list.

The problem was that different wiki pages had different definitions of
landuse=meadow (used to tag land used for hay and for grazing animals),
natural=grassland (mainly used to tag natural grassland/meadows) and
landuse=farmland (used to tag land used for tillage and for grazing
animals). The edit was an attempt to solve that issue.

Regards
Markus

On Mon, 3 Sep 2018 00:00 Martin Koppenhoefer, 
wrote:

> Another change I noticed which wasn’t discussed AFAIR:
>
>
> https://wiki.openstreetmap.org/w/index.php?title=Tag:landuse%3Dmeadow=prev=1515853
>
>
> Comments?
>
>
> Cheers,
> Martin
>
> sent from a phone
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] motorcar definition changed recently

[SelfishSeahorse]

Here's the weblink to Simon's explanation of motorcar=yes vs motorcar=no
from the past discussion:

https://lists.openstreetmap.org/pipermail/tagging/2017-November/034208.html

(The corresponding thread about a special road barrier started here:
https://lists.openstreetmap.org/pipermail/tagging/2017-November/thread.html#34194
)

On Mon, 3 Sep 2018 09:36 SelfishSeahorse,  wrote:

> The meaning of the motorcar key has been discussed some time ago with the
> conclusion that motorcar=no means 'no entry for any power driven vehicle
> except two-wheeled motor cycles without side-car', while motorcar=yes only
> means that motorcars are allowed. (Unfortunately i couldn't find the
> discussion yet.)
>
> So yes, i think the change should be reverted.
>
> Regards
> Markus
>
> On Sun, 2 Sep 2018 23:14 Martin Koppenhoefer, 
> wrote:
>
>> OMG the Germans have overtaken the wiki. I just noticed this change to
>> the motorcar access definition:
>>
>> https://wiki.openstreetmap.org/w/index.php?title=Key%3Aaccess=revision=1601167=1598869
>>
>>
>> https://wiki.openstreetmap.org/w/index.php?title=Key:motorcar=next=1532406
>>
>>
>> I used motorcar to mean automobile in the past, although most of the time
>> the restrictions were more general. motorcar=no meant probably also hgv=no,
>> but in access=no & motorcar=yes I don’t think that hgv=yes is implied.
>>
>> Cheers,
>> Martin
>>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Slow vehicle turnouts

[SelfishSeahorse]

Hi!

I'd propose to tag the section of the road with the turnout (or
alternatively just a node) turnout:=yes.

I would neither use a lane key nor a separate highway=service way, because
slow vehicle turnouts aren't lanes for moving traffic and because a
separate highway way would give the wrong impression that the turnout were
physically separated from the other lanes.

Regards
Markus

On Mon, 3 Sep 2018 12:31 Dave Swarthout,  wrote:

> I'm still trying to cook up a scheme where those pullouts can be added as
> a way and then tagged in a manner that reveals their purpose and function.
> The use of lanes may indeed be the most correct approach but to my way of
> thinking, it doesn't communicate the purpose of the "extra" lane very well.
> Because the turnouts use a separate lane, are very short in length, and
> are not really thoroughfares in the usual sense, might it be logical to tag
> them as service roads? As an example:
> highway=service
> service=slow_vehicle_turnout (or slow_vehicle_lane)
> lanes=1
> oneway=yes
>
> Opinions? Observations?
>
> On Mon, Aug 27, 2018 at 4:16 AM Kevin Kenny 
> wrote:
>
>> On Sun, Aug 26, 2018 at 4:11 PM Dave Swarthout 
>> wrote:
>> > >We also have the occasional spot like
>> > >
>> https://orthos.dhses.ny.gov/?Extent=-8283718.624472891,5242597.149663145,-8283317.927238801,5242833.029555047=2017_cache,2016_cache,2015_cache,2014_cache,2013_cache
>> > >There, we have an extra lane on the northbound side for the purpose of
>> > >getting by when the way is blocked by left-turning traffic
>> >
>> > My case is almost identical to the above illustration, except to
>> substitute the words "slow moving vehicles" for "left turning traffic". I
>> reckon I could use the lanes tagging but like Kevin, I have many "other
>> fish to fry" which is why I'm still looking for a simple one-tag-fixes-all
>> solution.
>>
>> My guess is that the slow-moving traffic is supposed to pull over into
>> the outer lane, allowing the parade behind to pass on the inside,
>> rather than the through traffic passing on the outer lane?  That's
>> like my first case, except that in that particular case, the climbing
>> lane goes on for several km (the highway is gaining a few hundred
>> metres of elevation up the Helderberg escarpment). We do have ones
>> that are more like pullouts rather than long lanes. There's a shorter
>> one on the westbound carriageway in
>>
>> https://orthos.dhses.ny.gov/?Extent=-8267325.730037971,5268580.377261018,-8265722.941101252,5269523.896828834=2017_cache,2016_cache,2015_cache,2014_cache,2013_cache
>>
>> By contrast, although the section is short, the outer westbound lane
>> in
>> https://orthos.dhses.ny.gov/?Extent=-8244541.671667748,5187738.535180551,-8244140.974433658,5187974.415072453=2017_cache,2016_cache,2015_cache,2014_cache,2013_cache
>> is NOT a climbing lane. It's set off by a single broken line, and
>> traffic is expected to keep to the right except to pass.
>>
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] landuse for government offices ?

[SelfishSeahorse]

I couldn't agree more.

Still sure that you don't want to resurrect the proposal? :-) I will
never be able to express my thoughts that well ...

On Thu, 20 Sep 2018 at 15:46, John Willis  wrote:
>
>
>
> > On Sep 20, 2018, at 8:49 PM, Colin Smale  wrote:
> >
> > But this discussion is about land usage
>
> Yes, and the Civic functions of governing a people are very different than 
> the usage of educating them, treating their health, selling them goods, and 
> manufacturing said goods. We have landuses (or at least area uses) for each.
>
> It's not about the buildings, nor the grass, but the importance people give 
> to the set activities and services performed by Civic representatives and 
> servants. That makes the location special - so it is mapped differently.
>
> We have a special name for the building they occupy, and often have large 
> multi-building complexes - with it's own name - that deserves the same level 
> of mapping granularity we give to office buildings, elementary schools, 
> malls, hospitals, industrial complexes, power stations, and transportation 
> centers.
>
> Even if all the buildings were *exactly the same* and sat on identical square 
> plots of land, owned by the same person, one after another down the street, a 
> fence separating each, with only the sign out front to denote their 
> differences - each would have it's point(s), it's building, and it's landuse 
> tagged in a different manner.
>
> I do not want to shoehorn in one type into another for no discernable reason, 
> other than "it looks like an office building" - nor does it represent the 
> "ground truth" in thousands of mappable landuses. It may not apply to your 
> area, but it sure does to mine and others around the globe - possibly in the 
> capital city of every region and country on Earth.
>
> Just because you don't feel it is necessary in your region, that is zero 
> justification for it's disapproval. There are other regions where it is 
> totally justified. OSM is flexible enough to handle all use cases if we have 
> enough categories of points, buildings, and a enough landuses to mix and 
> match to represent _all_ the types of situations, not just what you (or I) am 
> familiar with.
>
> Javbw.

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

Re: [Tagging] landuse for government offices ?

[SelfishSeahorse]

On Thu, 20 Sep 2018 at 10:40, Colin Smale  wrote:
> Maybe it's just me, but I really can't understand why landuse for government 
> functions needs its own tagging. The buildings are often indistinguishable 
> from commercial properties - what is different is that the occupier is some 
> statutory organisation.

It would never come to my mind to map the area where the parliament or
government meets as landuse=commercial. What kind of services should
they sell? Law? :-)

> We don't tag landuse=charity, or landuse=private, or landuse=education, so 
> why landuse=civic_admin?

Yes, i do tag landuse=education because there isn't any other land use
that fits better -- and apparently others are using it too (currently
used 489 times).

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

Re: [Tagging] landuse for government offices ?

[SelfishSeahorse]

On Thu, 20 Sep 2018 at 11:20, egil  wrote:
> I tend to agree with Colins arguments below, because in Sweden gov. agencies 
> are very mixed into the central spaces of cities but often not clustered 
> together in large complexes or whole areas.

Just because a tag would have no use in a specific area doesn't mean
it shouldn't be used at other places in my opinion. By the way: what
land use would you tag the perimeter of the Riksdag with?

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