Re: [Tagging] shop=pets/pet=*, are we missing a wiki page?

[Jeroen Hoek]

On 12-03-2023 09:27, Kai Michael Poppe wrote:

I will be getting on with documenting the most common values when I get back 
home.


I've taken the liberty to reword and clarify Key:pet, Key:pets, and 
Key:pets_allowed a bit, feel free to improve.


I've also opened the Talk-page for Key:pet:

https://wiki.openstreetmap.org/wiki/Talk:Key:pet

For this question in particular: whether Key:pet documents which pets 
are sold, or for which pets supplies are sold (or both). Lacking an 
initial proposal (I think), this tag is probably used both ways, but I 
might be wrong.


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

Re: [Tagging] shop=pets/pet=*, are we missing a wiki page?

[Jeroen Hoek]

On 11-03-2023 08:34, Kai Michael Poppe wrote:

while mapping a shop for dog supplies (shop=pets), I checked the wiki
if the combination with pet=* would be accepted.

Behold, Tag:shop=pets shows "Tags used in combination" to include
pet=*, yet Key:pet only is a disambiguation page for shop=pet and
pets=*...


Wow. The tags pet=* and pets=* definitely need better documentation due 
to their quite different use.


The meaning of pet=* (you can see for yourself: 
https://overpass-turbo.eu/s/1sjE) is clear enough, but the keys are 
really easy to mix up (note that you already mixed up shop=pets and 
shop=pet in your message).



So, are we missing a page describing the type of animals a shop sells
or sells accessories for?


Yeah, this calls for better documentation. The meaning of the tags is
pretty clear though, so that shouldn't be too hard.


Are we just gonna assume people will know what the English word for
the pet they want to tag is?


Sure. `cat`, `fish`, and `dog` are pretty basic vocabulary well within 
reach of, I would estimate, at least 99.5% of mappers. Documenting the 
most common values won't hurt, but while there will be some mappers who 
have no English proficiency at all, it is doubtful that documentation 
translation efforts will ever reach as far as the values of pet=* for 
more than a handful of languages — if that. You could implement a list 
of the most common values for pet=* for the shop=pet preset in ID, that 
could help.


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

Re: [Tagging] Use of crossing:island where crossings and islands are mapped separately

[Jeroen Hoek]

Where there is a crossing with traffic islands, but the highways forming the crossings and crossing the islands are mapped separately, my assumption has been that crossing:island=no is the correct tagging. 


I agree. My understanding is that you can provide information about 
pedestrian refuges at a crossing in two ways:


* By adding crossing:island=yes to the crossing node, and mapping the 
whole crossing from side to side with footway=crossing on the crossing 
way, including across the traffic island(s)
* By mapping the crossing separately leaving crossing:island out (or 
using 'no'), and mapping the actual crossing bits with separate 
footway=crossing on the ways between side(s) and traffic island(s)


It is my understanding that crossing:island=* only says something about 
the crossing way it sits on (ideally, tagged with footway=crossing), not 
all the crossings part of an intersection.


I've started using footway=traffic_island on the highway=footway for the 
bits in between (the 'pedestrian refuges' or 'traffic islands'). This 
helps other mappers understand the crossing and prevent accidental 
joining of the ways. For data consumers interested in accessibility, the 
mapped length of the actual crossings (tagged with footway=crossing and 
one or more highway=crossing nodes where ways/lanes intersect) can be 
interesting (e.g., for routers to penalize very long crossings without 
traffic islands).


I haven't used footway|cycleway=traffic_island on the ways crossing the 
islands, possibly because JOSM and/or Osmose (incorrectly?) complain. 
Perhaps I should?


JOSM should have stopped complaining about this by now. Values for 
footway=* where whitelisted due to a period where values for sidewalk=* 
where put in footway=* instead (e.g., footway=left). This is still part 
of the validation, but other footway-values are now treated as 
user-defined, which is in line with how footway=* is used.


Does Osmose complain about these?

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

[Tagging] Feature proposal - Vote result - parking=street_side (approved)

[Jeroen Hoek]

Good morning!

The voting for the parking=street_side feature proposal drafted by
Supaplex030 and myself has run its course. The proposal was approved
with 23 votes for and 2 against; there were no abstentions:

https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side

In the coming days the relevant parts of the wiki will be updated with
the information from the proposal.

Our thanks to everyone who voted, participated in the discussions, or
contributed with comments and advice!

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

Re: [Tagging] Feature Proposal - Voting - parking=street_side​

[Jeroen Hoek]

On 15-11-2020 11:11, Alan Mackie wrote:
> Never mind. I've just reread it and it seems I need more coffee.
No worries. Enjoy your coffee. :)

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

Re: [Tagging] Feature Proposal - RFC - parking=street_side

[Jeroen Hoek]

On 27-10-2020 09:30, Martin Koppenhoefer wrote:
> because in OpenStreetMap everything is “valid”, but both approaches
> are not equally good. In this specific case, as soon as
> landuse=highway is mapped as an area, having connected the adjacent
> landuses to the middle of the street will become utterly wrong and
> will have to be fixed, up to then, it just means generalizing at the
> expense of having everything on the road and sidewalks misrepresented
> as lying on the neighbouring areas.

Perhaps I could have better phrased that by stating that both approaches
are in common use, and from the perspective of our proposal both
approaches should work.

Personally, I agree.

In the example graphics we do focus on the separately drawn method where
the explicitly mapped method is discussed.

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

Re: [Tagging] Feature Proposal - RFC - parking=street_side

[Jeroen Hoek]

On 26-10-2020 21:24, Matthew Woehlke wrote:
> If parking is on both sides of the street, the parking area already
> crosses the street, and even if it doesn't, logically the parking area
> *does* connect to the street. I disagree with the argument that mapping
> thus is somehow "wrong", and indeed, I usually map parking that way.

I'm afraid there is no consensus on how to map features along a street
exactly. Similar to how some mappers glue landuse=relational (etc.) to
the street and some use the boundary of the combined plots of the block.

Both approaches are valid; the latter is more suitable where highly
accurate boundary data is freely available along with high resolution
satellite imagery (e.g., the Netherlands) and mappers.

Personally, extending the parking area over the carriage way feels like
mapping for the router, in that I would be drawing a parking area where
there is none just to reach the highway-line in the middle of the street.

You are right about mapping the spaces of course; I do so when possible.

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

Re: [Tagging] Proposal for admission=* tag

[Jeroen Hoek]

On 26-10-2020 17:52, Janko Mihelić wrote:
> I have a feeling the poi role is a bit vague. I would keep it optional,
> with only admission and issue being required for the admission relation
> to work.

Wouldn't issue be optional as well if any admission:issue:* tags are
used? For example, the roaming ranger scenario where no ticket shop exists.

You could consider requiring having at least one of those (an
admission:issue:* tag or an admission role member) for a valid relation.

> For example, your restaurant example, if the restaurant is poi, and one
> entrance is admission, what if someone adds a second entrance and
> forgets to add it to the admission relation? Then the system breaks
> down, and the router routes you through the second entrance.
> I would keep it simple, and add the whole restaurant as admission.
> 
> But I'm sure there are examples where a third role would be necessary.
> I'd like to keep this for a different proposal, and keep it simple for now.

That's understandable. How will you handle the theme park with
separately mapped entrances though?

If you omit the entrances from the relation, and these have something
like access=customers, routers won't know that there is an admission
relation with information on where to get tokens/tickets and what it
admits access to. Routers that try to use the admission relation, won't
know that they could offer navigation to the entrances, rather than to
the middle of the POI. Or am I over-thinking this?

If the entrances are role 'admission', and the ticket
office/shop/machine role 'issue', then where do you link the relation to
the park itself?

>>  admission:issue:*
> 
> I like this one. So in addition to relation members with the "issue"
> role, you can also get the ticket through all the admission:issue:xxx=*
> ways. I'll add it to the wiki.

Nice. :)

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

Re: [Tagging] Feature Proposal - RFC - parking=street_side

[Jeroen Hoek]

On 26-10-2020 19:31, Matthew Woehlke wrote:
> Alternatively, clients might look at the sort of highway running
> through a parking area. A highway=tertiary is probably "street-side
> parking", while a highway=service, service=parking_aisle probably is
> not.

That's not a bad thought, but it would require connecting the
street-side parking area to the highway (e.g., by extending the area to
the middle of the carriage way), which goes against the principle of
mapping what is there. I don't think renderers tend to have this
information available in any case.

Another notion I had was that renderers could just use capacity=* as a
measure of how visible a parking amenity should be, but that would
require knowing the capacity, which is not always plausible (and it
could lure mappers into tagging a capacity value they deem suitable for
rendering reasons). Of course, using capacity=* as well as parking=* can
be useful to highlight huge parking facilities at an earlier zoom-level
(I think Carto uses only the area size at the moment to do this).

All in all simply adding this sub-tag value seems the clearer option.

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

Re: [Tagging] Proposal for admission=* tag

[Jeroen Hoek]

On 26-10-2020 13:44, Janko Mihelić wrote:
> Although, now that I think of it, you can add the whole theme park
> to the relation, and add role "admission", that doesn't hurt.

I would use a separate role for the poi (point-of-interest) itself, so
data consumers know what the subject of the relation is (the poi), where
its places of admission (entrances) are, and where tickets are issued.

> With ski resorts, you would need to put all the aerialways in the
> relation as "admission", and ticket shops as "issue". You don't put
> the ski slopes or the whole ski resort with admission, because you
> can still hike through there, you just can't use the ski lifts.

If you have a ticket that grants access to several ski-lifts, you could
just create a relation with those ski-lifts as poi members.

> Another example is a big nature park. There is one or two official
> entrances, but you can just hike to that park without seeing any
> entrances or boards that say "You have to have a ticket". There is a
> possibility you buy a ticket from a ranger you accidentally meet. So
> do we put all the paths in that park in the relation? Or is putting
> the whole park boundary, and the oficial entrances enough?

Perhaps you can omit the admission role completely in that case. If the
poi (the park) is part of the relation, you would already know that a
valid ticket is needed. Additional tags on the relation could indicate
that you may be checked randomly at the poi.

You also document that omitting the issue role means that you have to
use other methods to acquire a ticket. You already propose
admission:website, so I would document that if that exists, data
consumers and users know that tickets can be bought online.

You might consider adding another addmission:* tag to indicate that
tickets may be bought from a roaming agent.

For neatness and extensibility, perhaps admission:issue:* can be used as
namespace for these? Data consumers then know that any admission:issue:*
key means tickets can be got there, and you can document the common
types (e.g., admission:issue:website, admission:issue:phone,
admission:issue:roaming=yes (or something like that, for the roaming
ranger edge case)).


So for the park example:

type=admission
name=Mihelić Park
admission:roaming_checks=yes
admission:issue:roaming=yes
admission:issue:website=https://example.com/tickets
admission:token=ticket;qr_code

poi -> (park outline)


For the ski-resort:

type=admission
name=Awesome Ski Resort Aerialways and Bar
admission:token=lanyard

poi -> (ski lift 1)
admission -> (ski lift 1)
poi -> (ski lift 2)
admission -> (ski lift 2)
poi -> (guest only après-ski bar)
admission -> (entrance of that bar)
issue -> (ticket shop in the village)
issue -> (ticket machine at summit of mountain)


Would that work?

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

Re: [Tagging] Proposal for admission=* tag

[Jeroen Hoek]

On 25-10-2020 14:55, Janko Mihelić wrote:
> Relations are definitely safer, but I wanted to add a unique name
> version for new editors that are intimidated by relations.
> Also for cases when you would have a lot of admission issuers, so we
> don't get some humongous relations. Maybe there's a venue for which you
> can buy a ticket in any kiosk in town. I would rather tag something like
> that with a admission:name=* than add all kiosks to a relation.

Using relations for the first time is tricky, you are right about that.
But there are a lot of places in OSM where relations are necessary. I
wouldn't worry too much about novice mappers not being able to use them.
Any mapper who can use the wiki to look up keys for a scheme like this
will probably be able to use JOSM to create relations.

When the proposal is settled down on the relation type and roles a
prefix could be created for JOSM to help create such a relation, further
lowering the bar.

I wouldn't be too afraid of large relations, but you might want to add
that the ticket office and the poi should (ideally) be geographically
close-ish (like, within the same city or area). This is similar to what
the site-relation documentation states.

I mentioned this on the wiki as well: it might be nice to add an
optional role to your relation for the actual entrances (e.g.,
turnstiles), in addition to the ticket office and the poi, where tickets
are checked. For something like a theme park these are definitely
mapped, and a clever router could suggest a route going from the ticket
office to an entrance with that data available.

This looks like a useful proposal.

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

Re: [Tagging] Feature Proposal - RFC - parking=street_side

[Jeroen Hoek]

On 24-10-2020 22:27, Allroads wrote:> Use area:highway for polygon and
parking!

I will clarify the relation of our proposal to area:highway, thanks for
pointing it out.

In brief, the two tagging methods coexist and complement each other. Our
proposal focuses on the parking-amenity (and thus amenity=parking)
aspect of these street-side parking areas.

Anyone mapping with area:highway can of course use
amenity=parking|parking=street_side, and either:

* include the parking areas within a area:highway=residential or similar;
* use area:highway=service;
* or not include them within the highway area and leave them as-is.

What the right approach is, is probably beyond the scope of our
proposal, and should be discussed within the scope of the area:highway
proposals instead.

I think it suffices to say that amenity=parking|parking=street_side
complements area:highway mapping if applied, but doesn't require it.

> For me,  the value "parking_space" what key, single space problem must
> be fixed first to say something about "street_side". As it comes to a vote.

Could you elaborate?

amenity=parking_space can be used as usual within amenity=parking. This
of course also works with amenity=parking/parking=street_side:

https://www.openstreetmap.org/way/849745989

Our proposal doesn't affect the documented use of amenity=parking_space;
you would use it just the same as with parking=surface.

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

Re: [Tagging] Feature Proposal - RFC - parking=street_side

[Jeroen Hoek]

On 24-10-2020 23:54, Paul Allen wrote:
> So tagging for the renderer because, in your opinion, these car parking
> areas are unimportant.

By that line of reasoning tagging highways anything other than
highway=motorway is tagging for the renderer.

I understand your concern, but no, it is not our opinion that these car
parking areas are unimportant (we wouldn't map them if we thought so).

This proposal is not about declaring one type of parking more important
than the other. It does standardise a new parking=* and parking:lane=*
value for a distinct, commonly mapped, and ubiquitous type of parking area.

Because of the way these features are present on the ground, it makes
sense for a renderer to consider a different rendering approach than
they would for a parking garage of parking lot. And yes, for a general
purpose map, that may involve de-emphasizing them.

In the Netherlands we've had a case where a misguided mapper imported
this type of street-side parking area in one city (the import was not
properly discussed and documented and has since been reverted). They
used amentity=parking_space on those areas instead of amenity=parking
(even though most contained at least two parking spaces), because they
didn't like the way amenity=parking rendered on Carto with hundreds of
parking areas mapped.

That is tagging for the renderer. We want to prevent that.

By introducing a relevant sub-tag value renderers and routers may act
on, we prevent tagging for the renderer, and encourage the use of a
semantically correct tag-value. A collatoral effect is that the existing
parking=* values will become less abused (e.g., surface and layby) for
street-side parking. Mappers who want to map street-side parking, can do
so knowing that any rendering issues can be dealt with by any renderer
on the base of the correct sub-tag value.

Whether renderers will act on this or not is of course a stylistic
choice not part of this proposal, but we do offer some suggestions
(under 'Rendering').

Of course, I can fully imagine some types of map or overlay that
actively highlight street-side parking! For example some sort of
'parking-mode' on a router's screen when you are nearing your
destination. Similarly, some users may prefer street-side parking over
parking garages (camper/RV owners perhaps), and instruct their router to
filter on those.

Our proposal facilitates this: renderers can render street-side parking
however they wish, because the tag tells them it is street-side parking.

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

Re: [Tagging] Feature Proposal - RFC - parking=street_side

[Jeroen Hoek]

On 24-10-2020 16:22, Janko Mihelić wrote:
> These two variants are mapping for the renderer, and both add false
> data. The first one extends the parking over half the road. The second
> creates a service road area over half the road. There is no service road
> area there, you are just trying to connect the parking to the road so it
> looks nice on the map. And it does look nice, but it's false data.

Agreed.

There may be a handful of cases where a router won't route you to a spot
on the road right next to an explicitly mapped parking=street_side area
mapped the way shown in our proposal, but I don't think that is a very
common use case; you normally wouldn't target a specific street-side
parking area.

If I want to visit a friend or a small shop in an area without dedicated
parking lost/garages, I would look around on the map to orient myself,
and probably set the destination to the address I am going, or somewhere
along a road from whereon I would go look for a free spot using the map
to show me streets where I can park.

With a large parking garage you definitely would select that as the
destination if you are using a router, but that is a different kind of
beast.

> Street side parking is a very different parking area from a big enclosed
> surface parking. Some people may find it hard to park there because you
> back up onto traffic, and they may want to avoid parking there. This
> information is definitely very useful.

Exactly. Our proposal should benefit other types of amenity=parking such
as parking=surface (etc.) by giving routers and renderers a way to
ignore and de-emphasize, respectively, street-side parking.

It also benefits data consumers (including routers) when asking for a
list of parking facilities nearby: street-side parking can be properly
classified and described as such, and potentially shown lower in the
list below any public parking lots/garages.

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

Re: [Tagging] Feature Proposal - RFC - parking=street_side

[Jeroen Hoek]

On 24-10-2020 15:58, Paul Allen wrote:
> I don't see any valid reason for wanting to de-emphasize them and you
> do not attempt to provide one.  Maybe there is a valid reason but I
> don't see it.

Thanks for the feedback; we'll clarify that point. From the proposal:

> Furthermore, this type of parking may have different rendering and
> navigation needs compared to other types of parking (see below).
This is mainly about preventing the visual clutter of blue P's that are
the result of tagging amenity=parking without any parking sub-tag or an
unsuitable one. Street-side parking usually isn't of interest until you
are in the area or are orienting yourself for a trip to visit a POI
nearby. Unlike dedicated parking facilities (like a parking lot or
parking garage), the scale of these is much smaller, yet they are also
much more ubiquitous.

Parking=street_side allows for renderers to de-emphasize these areas
(for a few suggestions, please see the proposal under 'Rendering'),
without sacrificing the findability of dedicated parking lots/garages
(especially if these lack capacity information).

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

Re: [Tagging] Feature Proposal - RFC - parking=street_side

[Jeroen Hoek]

On 24-10-2020 15:58, Paul Allen wrote:
> What you haven't convinced me of is that it isn't amenity=parking.
> By any rational definition it is.  I know of off-carriageway parking
> which is controlled by a county council and has a ticket
> machine.  The county council lists it as a car park, one
> of three car parks in the town, and makes no distinction.

It is amenity=parking. The proposal proposes a new value
parking=street_side. This is in addition to the parent tag amenity=parking.

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

Re: [Tagging] Feature Proposal - RFC - parking=street_side

[Jeroen Hoek]

On 24-10-2020 15:11, Paul Allen wrote:
> As rendered it appears you need a skyhook or
> a cargo helicopter to park.  Not good.  You're probably as unhappy with that
> method of tagging as I am.

True, but the same goes for lots of points-of-interests and other mapped
parts of the urban landscape; e.g., patches of grass, shrubs, benches,
bicycle parking areas, etc. In all these cases mapping the exact area
results in a neat map that makes sense for orientation as well as
finding parking spaces for motorists in the neighbourhood.

While being able to route exactly onto a point-of-interest is valuable
in some cases, for the use case of this proposal I would say that it is
not as relevant. Besides, if someone really wants to navigate to a
specific mapped street-side parking area, their router will tend to
route to the nearest point it can get too, which more often than not
will be right in front of the parking area.

This proposal provides tag-values for a common type of parking area
already mapped in great quantities, and hard to ignore at a certain
level of detail. It gives mappers a way to map them without bending
existing tags (e.g., parking=surface, parking=layby), and it eventually
gives renderers a way to de-emphasize them (the proposal has a few
suggestions) compared with the more 'high-value' parking facilities like
large capacity public parking=surface|multistory|underground.

If applied consistently, this proposal will increase the relevance of
parking areas that really are parking=surface|layby|etc.

Kind regards,

Jeroen Hoek
Co-author of this proposal

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

Re: [Tagging] Linking Sidewalks to Highways

[Jeroen Hoek]

On 22-09-2020 23:37, Martin Koppenhoefer wrote:
> renderers have all the necessary information to omit name for 
> footway=sidewalk. It is just a question of the style 

Granted, for footway=sidewalk renderers could omit the name.

The sidepath:of:name approach has the benefit of more explicitly
declaring a way a 'sidepath of' though, and works for cycleways,
bus-lanes, etc. too.

Mappers might also be rightly hesitant to name sidewalks explicitly,
because it will make for many chaotic maps depending on the renderer.
Tagging for the renderer is bad, but adopting an approach that causes
widespread rendering issues isn't all that great either.

I don't think these two approaches need exclude each other though.

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

Re: [Tagging] Linking Sidewalks to Highways

[Jeroen Hoek]

On 21-09-2020 12:02, Supaplex wrote:
> The main categories of the highway, "name" and its classification like
> "primary/secondary", can be assigned to the separate way with Keys like
> "sidepath:of" or "sidepath:of:name". Other values like "lit" should
> anyway be tagged directly on the separate way.

I like sidepath:of:name.

sidepath:of:name would have the benefit of solving another issue with
mapped parallel ways that conceptually belong the same 'road'; it would
give (pedestrian, cyclist) routers a name (and a reference to the nearby
feature containing all name-tags) to use in the instructions, while
renderers can avoid them.

The current practice for parallel footways is to leave them unnamed, but
this chafes a bit because they do tend to share the name of the way
mapped in the centre of the full road (or rather, the whole 'road' from
sidewalk to verge to street to cycleway to sidewalk is usually what is
named).

Explicitly naming sidewalks and all other parallel ways makes for a
maintenance burden and would create a very busy rendering on most map
styles without really benefiting the user, but sidepath:of:name means
only the name-tag has to match (any other tags such as loc_name,
official_name, short_name, and name:xx can be left on the 'main' street
way(s)).


Example:

This sidewalk:
  https://www.openstreetmap.org/way/722895152
And this cycleway:
  https://www.openstreetmap.org/way/804929281

Would both get: sidepath:of:name=Grovestins

To declare them parallel ways of:
  https://www.openstreetmap.org/way/722895144
  (just one section of the longer road)


Also great for parallel bus/tram lanes etc.

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

Re: [Tagging] Linking Sidewalks to Highways

[Jeroen Hoek]

On 22-09-2020 12:30, Peter Elderson wrote:
> Jeroen Hoek mailto:m...@jeroenhoek.nl>>:
> 
> I have been applying highway=cycleway + cycleway=link as well to see how
> this feels. Some early documentation I have been preparing:
> 
> https://wiki.openstreetmap.org/wiki/User:JeroenHoek#cycleway.3Dlink
> 
> 
> Why the diagonal link to the center intersection node? 
> Wouldn't it be more logical / practical to continue the cycleways
> straight up to the way of the crossing road?

Yeah that might be nicer.

> No link tag needed there, I think. 

I'm trying to be consistent in the way I apply that tag. Here is a more
concrete example: https://www.openstreetmap.org/way/136991284

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

Re: [Tagging] Linking Sidewalks to Highways

[Jeroen Hoek]

On 22-09-2020 00:17, Clifford Snow wrote:
> It's the type of connection, going from sidewalk or dedicated bike path,
> to road where I've felt we need a highway=footway_link/cyclway_link or
> maybe footway_connector/cycleway_connector, to connect separated
> sidewalks/cycleways to the street in instances exactly like this.

There is highway=footway + footway=link proposed by SelfishSeahorse,
which suits this purpose:

https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:footway%3Dlink

I have been applying highway=cycleway + cycleway=link as well to see how
this feels. Some early documentation I have been preparing:

https://wiki.openstreetmap.org/wiki/User:JeroenHoek#cycleway.3Dlink

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

Re: [Tagging] "width" on streets: Time for a recommendation

[Jeroen Hoek]

On 15-09-2020 10:09, Martin Koppenhoefer wrote:
> Am Mo., 14. Sept. 2020 um 20:37 Uhr schrieb Supaplex
> mailto:supap...@riseup.net>>:
> indeed, mapping the width generally requires measuring the width, and it
> is often not practical (unless you are willing to spend a lot of time or
> have very good aerial imagery at hand).

It will vary a lot per country and the available resources. In the
Netherlands we are blessed to have both yearly 25cm satellite imagery,
and municipal topography outline layers available. Those two, combined
are really quite nice to have.

In JOSM it looks like this:

http://jeroenhoek.nl/temp/josm-dutch-bgt.png

Measuring the width of a street (option 2) is often trivial with these;
in this case it seems to be a neat 6m.

I wonder if it is feasible to have JOSM render the width, optionally, as
a sort of semi-transparent background beneath the way-line. It would
make aligning these to the middle of the street even easier, and tagging
the width less error prone too due to the visual feedback.

Jeroen Hoek

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

Re: [Tagging] Confusion bicycle_road <> cyclestreet

[Jeroen Hoek]

On 26-08-2020 14:42, Volker Schmidt wrote:
> What is the "saving" n using the cyclestreet=yes tagging? […] 
> Basically I see no need for separate tags like bicycle_road and 
> cyclestreet, as you can easily describe their properties with 
> existing tags. Add to this the confusion between the two tags, and 
> then add to the mix the myriad of variants on the subject in 
> countries other than Germany and Belgium, respectively.

I can't comment on bicycle_road, but as for cyclestreet the wiki gives a
fair description:

> A cyclestreet is a street that is designed as a bicycle route, but 
> on which cars are also allowed. However, this car use is limited by
> the character and layout of the cyclestreet.
> 
> Bicycles are the primary users of the street, while motor vehicles 
> are secondary.

All other tags like maxspeed and overtaking:motorcar are useful, but
tell the consumer nothing about the inherent nature of the cyclestreet,
which is a shared road that is by design bicycle-friendly. This goes
beyond taggable properties (e.g. traffic flow to and from such streets
in the broader city grid is taken into account, there are no speed
barriers that are bicycle-unfriendly).

The tag cyclestreet=yes can serve some purposes I can think of:

* Rendering these streets differently on (cycling) maps (like a blend
between a normal street and highway=cycleway)

* Prefer them in cycling routing engines over streets lacking cycling
facilities

* Penalize them in car routing engines

It is analogous to highway=cycleway: you can easily use highway=service
and add a bunch of tags making it a cycleway in terms of access rights,
but a cycleway implies much more than that (like safety and
suitability). The cyclestreet=yes tag is similar in this respect.

Jeroen Hoek

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

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

[Jeroen Hoek]

On 09-02-20 12:36, Peter Elderson wrote:
> For the record, I am not opposed to renderers, data users or toolmakers
> reporting a problem or an improvement request and asking the taggers
> list to come up with a solution everyone can live with. Information in
> the database should be renderable and usable, because that is the
> purpose of the whole thing. But please, in co-operation, and when a
> sudden change leads to problems, rethink it and take another path to get
> to a shared solution.

+1.

It would probably suffice to restore just the rendering for
`barrier=hedge` plus `area=yes` for now.

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

Re: [Tagging] Tagging small areas of bushes, flowers, non-woody perennials, succulents, etc

[Jeroen Hoek]

On 09-02-20 03:33, Joseph Eisenberg wrote:
> In the discussion about `barrier=hedge` areas, it is clear that
> mappers want a way to tag small areas of bushes and shrubs, and not
> everyone is happy about using natural=scrub for this case.
> 
> Currently there is a tag landuse=grass for small areas of managed
> grass, but this might be considered to exclude other non-woody herbs.
> And leisure=garden is usually considered the whole area of a garden,
> rather than being limited to a certain type of vegetation.
>
> I would suggest that we need a more developed system of tags for
> micro-mapping small areas of plants, not just woody-stemmed bushes and
> shrubs, but also semi-annuals, herbaceous perenials (e.g. in the
> tropics) and annual flowers and herbs.

Agreed. This is basically what the landcover proposal set out to do.

`landuse=*`, `amenity=*`, and `leisure=*` all (primarily) describe the
human use of the area, whereas the tagging of patches of grass, bushes,
flower beds, etc. describes what covers the land (usually within one of
the human-use tags, e.g., `leisure=park`).

> This would also help with problems like using village_green for all
> sorts of areas: see discussions and examples in
> https://wiki.openstreetmap.org/wiki/Talk:Tag:landuse%3Dvillage_green
> 
> Rather than just discussing how the tag small areas of bushes or
> hedges, how about how to tag this area of flowers:
> https://wiki.openstreetmap.org/wiki/File:Vg6.jpg
> 
> Or a garden bed planted with these:
> https://www.thaigardendesign.com/bird-of-paradise-strelitzia/ - or
> these: 
> https://www.wikilawn.com/flowers/ornamental-red-ginger-plant-alpinia-purpurata/
> 
> Or this bed full of succulent plants, in a semi-arid region:
> https://www.finegardening.com/app/uploads/sites/finegardening.com/files/images/spotlight-collection/resize_of_pa230150.jpg

By adopting the landcover-tag there will be a clear base-tag for
anything that qualifies as landcover. Introducing new tags should be a
lot more straightforward. Certainly compared to the current ambiguous
set of `landuse=grass`, `natural=scrub`, and `barrier=hedge`.

> Are people micro-mapping areas such as these?
> 
> How specific should the tagging be?

https://wiki.openstreetmap.org/wiki/Proposed_features/landcover makes a
valiant attempt at answering that, but the landcover-tag is by its
nature as a single top-level tag for landcover extensible.

Also:

https://taginfo.openstreetmap.org/keys/landcover#values

I found the two cases of `landcover=rubber` a particularly creative form
of micro-mapping, and couldn't figure out why anyone would cover the
ground in rubber until I saw that it was used inside of a
`leisure=playground`, where it makes sense.

Of course, as anyone who supports the landcover-proposal knows,
landcover-tags cannot really be used on their own at the moment. If I
map in the Netherlands, where an initial import used `landuse=grass`,
`natural=scrub`, and `natural=forest` to broadly map land cover, I have
to double-tag these features with the tags that get rendered on
OSM-Carto, *and* the `landcover=*` tags I want to support, because not
doing that would mean that in the eyes of many users I leave empty areas
where there once was (roughly drawn) colour. That breaks my rule of
making a nice map.

It all boils down to what Paul Allen rightly calls joined-up thinking:

* Many mappers wish to map right down to the level of flower beds and
shrubs, and especially in urban settings this often results in rather
nicely mapped areas

* The landcover-proposal exists, is well thought out, and the top three
tags exceed 1 instances of use each, despite not being rendered, and
not being supported as presets in JOSM and Id, which makes sense,
because they're not rendered as opposed to their legacy counterparts.

* Carto-OSM points out inconsistencies in the use of `barrier=hedge`,
attempts to resolve the situation but breaks existing use, but any
proposed solution to allow for the rendering of hedges drawn as areas is
shot down because it would mean converting tags from something that did
render (and now renders brokenly) to something that doesn't render, and
likely won't render for years.

So once again any progress on this front stalls indefinitely, mappers
move on and keep on using whatever renders for these features, and
eventually all hedges mappes as areas will be replaced by
`natural=scrub`, because it renders something green and isn't broken,
which is a step forward from the current situation.

Most of the time new tags can be introduced gradually and organically,
starting with unrendered use, modest proposals, and eventually presets
in the editors and rendering on OSM-Carto. For some more complex
situations like this landcover/hedges problem, a more integrated
approach may be more fruitful.

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

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

[Jeroen Hoek]

On 06-02-20 13:29, Peter Elderson wrote:
> Joseph Eisenberg  >:
> 
> The Netherlands has been claimed as a place where barrier=hedge areas
> are used properly and are necessary. I have already downloaded one
> whole provicne, Zeeland, which has quite complete landcover and
> landuse mapping due to an import. In Zeeland there are 149 uses of
> `barrier=hedge` on a closed way without `area=yes` or landuse=,
> natural= or leisure=, and only 12 closed ways with `barrier=hedge` +
> `area=yes`.
> 
> 
> Zeeland, of all places... Most of Zeeland is water, dykes and polders. 
> 
> Try Noord-Brabant, Zuid-Holland, Utrecht. 
> 

Absolutely! Zeeland is a really unfortunate choice to illustrate this issue.

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

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

[Jeroen Hoek]

On 07-02-20 17:58, Martin Koppenhoefer wrote:> interestingly, for paths
and roads there is also an area=yes variant
> (which is likely more common than the newer "area:highway" tag, which
> has different semantics).

To be precise: `area=yes` on a `highway=*` means that the whole area is
routable, not just the (closed) way surrounding it. I.e., clever routing
software could send someone along a (shorter) path across the area
instead of along its sides.

Its semantics match that of `barrier=hedge` plus `area=yes`.

`area:highway=*` is more akin to `landcover=*` in that it represent the
surface area of the road, where `highway=*` represents the linear route
of the road.

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

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

[Jeroen Hoek]

On 06-02-20 05:22, Marc Gemis wrote:
> My interpretation is the same as Paul's. Including the not thought
> through part, as I never needed that.

Mine too.

There is only a subset of barrier-tags where `area=yes` makes sense,
like hedge and (city-)wall.

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

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

[Jeroen Hoek]

On 05-02-20 20:17, Christoph Hormann wrote:
> But that is not in any way sustainable and it would be highly 
> confusing for mappers because the conditions resulting in this 
> rendering would be unique and could not be derived from any general 
> principles.

I understand the reasoning, but what mappers see now is:

> You thought you could map hedges as areas using `area=yes`, the wiki
> told you that, and you've seen it done like that everywhere, but
> it was wrong, there is no way to map hedges as areas, and all those
> hedges you and your fellow mapper mapped are now tens of thousands
> of errors on the map.

That is, to put it mildly, quite confusing, not to mention
disheartening. It will also result in less-involved mappers remapping
the damage by turning hedges into scrub on the map. The only
alternatives are redrawing them as linear features (losing detail in the
process, and feeling like a massive waste of time) or removing them
completely.

Surely we can come up with a more constructive way forward?

Keeping the rendering for `barrier=hedge` plus `area=yes` for the time
being seems sensible and in keeping with the general use of those two
tags in combination.

If a tagging can be agreed on that can work for several applicable
barrier-values mapped as areas, then that can gradually replace the
`area=yes`-way for hedges. At some point the rendering for the old way
can be turned off to help mappers migrate, but there has to be some
overlap in time.

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

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

[Jeroen Hoek]

On 05-02-2020 16:10, Paul Allen wrote:
> 4) Where the only tags are barrier=hedge + area=yes then render
> as before, a hedge that has area.  

There are some additional tags that should be allowed for. Including
(mainly?) `height=*`.

> 5) Introduce, and render, landcover=hedge so we can tag an object
> as landcover=hedge + barrier=hedge.

That is actually a neat solution too.

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

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

[Jeroen Hoek]

On 05-02-2020 15:46, Christoph Hormann wrote:
> the semantic ambiguity of the > 350k cases where barrier tags are currently 
> used as a secondary tag on 
> landuse/leisure/etc. polygons to incidate the polygon is enclosed by a 
> linear barrier.

The PR specifically removes the filled rendering from `barrier=hedge`
mapped with `area=yes` from 36665 hedges.

There are 36665 hedges mapped with `area=yes`. These appear to be mostly
used for hedges drawn as an area, which follows the existing documented
convention. The PR effectively deprecates the combination of
`barrier=hedge` plus `area=yes` for hedges drawn as areas, because
`area=yes` may have been intended for one of the other tags on that
entity (which breaks the 'one feature, one object' good practice),
without providing an alternative.

No one is disputing that `barrier=hedge` on a polygon without `area=yes`
should not be considered a filled area. That part of the PR is good and
does not break the existing convention.

> it should be noted that barrier=hedge is currently 
> not the dominant method of mapping strips of trees or bushes with 
> polygons
A hedge is not the same as bushes or trees. Where bushes or clumps of
trees may form some sort of barrier (although you can often barge
through them), hedges predominantly are.

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

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

[Jeroen Hoek]

This update has the unfortunate side-effect of breaking the rendering of
over 1 hedges in the Netherlands. We have been very fortunate to
have access to highly detailed mapping sources via our government,
including both satellite images and tile-services for street-level
features, including hedges in public spaces.

This means that hedges are often mapped as areas, using the documented
tag pair of `barrier=hedge` plus `area=yes`:

https://wiki.openstreetmap.org/w/index.php?title=Tag:barrier%3Dhedge=1934515

(§ 'How to Map')

This update renders those hedges as linear features instead, creating
holes in the map where none exist.

Because there is no alternative to tag hedge areas, we now have a bunch
of broken hedges on OpenStreetMap.org's standard layer.

I wouldn't mind migrating away from `area=yes` to some alternative
though. `area:barrier=yes` might be suitable, and would allow for the
much desired walls-as-area to be rendered as well without ambiguity as
to the meaning of `area=yes`.

My proposal would be to allow barriers to be explicitly defined as areas
by adding `area:barrier=yes` to the tags, in addition to `barrier=*`.

The reason for the presence of `barrier=*` is that for routing software,
the edges of an area *are* the effective barrier, and nothing needs to
be changed in routing software to work with this proposal (in this
sense, this proposal is slightly different from `area:higway=*`, where
the `highway=*` is not usually present on the same entity, but drawn
separately instead).

The current lack of a migration path does make for a rather jarring change.

On 03-02-2020 13:41, Joseph Eisenberg wrote:
> That appears to be a "shrubbery" in British English, around a tree. It
> isn't wrong to use barrier=hedge, since it does provide a visual
> barrier and you will probably want to walk around it.
> 
> But there is not a very well established way to micro-map very small
> areas of shrubs and bushes like this.
> 
> Some mappers seem to use natural=scrub, others use leisure=garden, and
> some have tried various rarer tags with values like "greenery". There
> does not seem to be a consensus.
> 
> You might ask on the Tagging list to get some more ideas:
> tagging@openstreetmap.org
> 
> - Joseph Eisenberg
> 
> On 2/3/20, Marc Gemis  wrote:
>> Hello Joseph,
>>
>> I noticed Remove polygon fill rendering for barrier=hedge areas (#3844)
>>
>> So I wonder how I should map something like
>> https://www.mapillary.com/map/im/-tERxnfwcP3qlBh-0j7pnw now. For me,
>> that was barrier=hedge; area=yes. But from what I understand from the
>> discussion on Github, this is considered wrong tagging.
>> Should this be mapped as natural=scrub in your opinion?
> 
> ___
> 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] Tagging for emojis names

[Jeroen Hoek]

On 07-01-20 14:14, Rory McCann wrote:> Countries in OSM should already
include the ISO3166 code as a tag. Data
> consumers, or OSM based search engines, could just interpret the emoiji
> search term as 2 regular ASCII characters, and do the look up there. No
> need for a separate emoiji tag.

That is a good suggestion, but the problem is that not every ISO 3166
code is a valid Regional Indicator Symbol pair. There are also other
codes that cannot be derived from the ISO 3166 code, such as the flags
for England, Scotland, and Wales, which are represented by a different
Unicode/emoji mechanism called Tags (e.g., the flag of Scotland is
represented by the Unicode emoji  (waving black flag) followed by the
tag-characters 'gbsct').

See: https://en.wikipedia.org/wiki/Tags_(Unicode_block)

> If you add it as a separate tag, then there's the risk that data becomes
> different from the ISO code.

I'm not too worried about that. Countries tend to remain rather stable
on the map; any changes usually imply countries changing names (and
regimes), splitting up, or combining with other countries, and garner a
lot of scrutinization. I would wager that name:Zsye will be updated
before at least half of the other name-tags is.

Jeroen Hoek

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

Re: [Tagging] Tagging for emojis names

[Jeroen Hoek]

On 06-01-2020 23:44, Hauke Stieler wrote:
>> I could sort of understand if a business name was an emoji, rather than
>> real words, but I'm not aware of any cases of this?
> 
> But I would tag a pure emoji-name of a company using the normal "name"
> key. However I'm also not aware of any case.

There seems to be some confusion about what name:Zsye is about. While
the ISO 15924 script code 'Zsye' is labelled 'emoji', the edit proposed
by Ferdinand0101 mainly introduces Regional Indicator Symbol pairs for
countries. These pairs tend to resolve to those countries' flags, e.g.,
, which you may see rendered as the Dutch flag, is composed of two
of these Regional Indicator Symbols that represent 'N' and 'L' (i.e., 
and ).

If done correctly, this would mean you could search OSM for a flag
copy/pasted from somewhere (like chat), and get the region represented
by that flag as a search result.

So to me it seems that this isn't so much about getting the emoji for
the Statue of Liberty to resolve (although that is possible), but more
about being to use country flags to search OSM for the corresponding
country.

Of course the proposal should reflect on how to ensure the correct
Regional Indicator Symbol pairs are added. One way to do this, is by
using the exsiting ISO3166-1:alpha2 and flag keys, and verify that the
flag rendered via Regional Indicator Symbols matches the flag-value.

Jeroen Hoek

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

Re: [Tagging] Tagging shared campuses: landuse=school?

[Jeroen Hoek]

On 05-04-19 23:10, Markus wrote:
> There is a minor thing, but i think that the landuse=* value should
> rather be educational (adjective) instead of education (noun). This
> makes more sense and fits better to other landuse=* values like
> residential, industrial or commercial.

I strongly agree. However, landuse=education is already in use (~500
times), whereas landuse=educational use borders on non-existent.

If landuse=education is used for the proposed purpose, than it might be
easier to simply adopt it. I'll look more closely at the actual use of
this tag to see if this is the case.

> In my opinion, landuse=school is too specific.

I am inclined to agree there too. One solution is to consider
landuse=school a specific sub-class of landuse=education(al). This my
proposed solution for now. Anyone not interested in the difference
between the two can just treat them the same.

But if it turns out that the number of landuse=school instances that
aren't linked one-to-one to amenity=school is on the low side, it might
be better to suggest deprecating it completely in favour of
landuse=education(al). That is, the gist of the original French proposal
is right, but going for the broader landuse=education(al) is a better
fit for the issues it solves.

I'll do some research on the actual usage to find out which way forward
is sensible.

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

Re: [Tagging] Tagging shared campuses: landuse=school?

[Jeroen Hoek]

On 04-04-19 15:41, Florian Lohoff wrote:
> Schools have forever been landuse=residential as schools belong to 
> residential areas.

This is not always the case, especially in cases where schools share a
common campus.

> Introducing yet another special landuse is just more confusing and it
> does not fix a single issue.

It fixes the issue documented by the original proposal, extended with
the issue I've described (higher education institutes sharing a campus).

> When schools share campus make it a large amenity=school area
> without any name and amenity=school + name nodes for the schools.

But the area itself is often named, and signposted as such (see the
French example in the OP mail).

To be clear: most mappers won't have to use these tags. They are implied
for the common case of one school, one school grounds. This is similar
to how amenity=place_of_worship/landuse=religuous works.

This proposal also co-opts existing tags rather than creating new one.
Does that assuage your concern for landuse=confusion?

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

Re: [Tagging] Tagging shared campuses: landuse=school?

[Jeroen Hoek]

On 04-04-19 15:55, Martin Koppenhoefer wrote:
> for the shared name of several schools I would suggest the group
> relation. Just add the schools as members and add the shared name to
> the relation.

Wouldn't that leave only the collective schools' relation with a
searchable name, rather than a named area rendered on maps that support it?

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

Re: [Tagging] Tagging shared campuses: landuse=school?

[Jeroen Hoek]

On 04-04-19 13:51, Martin Koppenhoefer wrote:
> why not overlap the amenity=school (one for each school, including the
> grounds)? This allows to show that it is a common campus, while
> otherwise you only associate the buildings with the school and make no
> statement about the campus, other than it is used by some (undefined)
> school. It also leads to better results in search (shows the whole
> school area), without any modification of the existing system. You could
> exclude those buildings from the area which are not part of the specific
> school.

This doesn't solve the common case of the shared campus or location
having a shared name, as in the French example I've linked to. A common
case in my experience; I have a named campus in my hometown that houses
a university, a college, and a research institute — each a distinct
organisation. The campus name is used in signage.

The association of school with campus can be deduced from the amenity
point/way lying inside the landuse area. This is the same as
amenity=place_of_worship inside a landuse=religuous.

I think the school amenity may also be linked to its grounds via a
relation, but that would go beyond the scope of this proposal.

Overlapping amenity areas also seem to go against the grain of most OSM
tagging solutions.

> landuse=school also conflicts with situations where a school is inside
> an administration (or other) building, but these may be few.

In these cases the current situation remains: using a node (or a way for
part of a building) for the amenity. The landuse for such a place might
eventually be one of those proposed in the landuse=civic proposal. I
think this is mostly an edge case though.

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

Re: [Tagging] Tagging shared campuses: landuse=school?

[Jeroen Hoek]

On 04-04-19 11:25, Mateusz Konieczny wrote:
> 
> Apr 4, 2019, 9:55 AM by m...@jeroenhoek.nl:
> 
> Then, landuse=school (~5000 in use)
> 
> Note that about 80% of landuse=school was added by automatic edits:
> https://user-images.githubusercontent.com/5439713/47250831-3d2e6b00-d429-11e8-9aef-1ba334ebecaa.png
> spikes indicate that it was added by mechanical edit or import
> 
> 74% of landuse=school objects have amenity=school anyway -
> (checked with http://overpass-turbo.eu/s/HFl and
> https://taginfo.openstreetmap.org/tags/landuse=school#overview )
> 
> --
> speculation below
> --
> 
> It looks to me that it is likely that someone though that all areas
> needs to be covered by one
> of landuse=* values and added duplicated tags to amenity=school areas.

Agreed. This means the number of uses I've quoted are mostly incorrect
(or more specifically: redundant) uses of this tag.

I still think the proposal (my version and the original one) is valid,
but for the sake of discussion the numbers I quoted should not be
exclusively taken as landuse=school and landuse=education in use for the
proposed problem; i.e., multiple educational amenities sharing a campus.

Combining landuse=school with amenity=school is not wrong, just
redundant if we consider school grounds tagged with amenity=school to
imply that type of landuse (which both proposals do). It think that
combination should be discouraged (as the wiki does) and might even be a
candidate for automatic merging.

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

[Tagging] Tagging shared campuses: landuse=school?

[Jeroen Hoek]

# Background

When tagging a school, as per the current documentation, ideally the
amenity=school tag is applied to the school grounds, implying its
landuse. This works fine for single schools that have their own
building, on their own grounds.

However, in many countries schools can share a common campus. To
facilitate mapping these, the landuse=school proposal was drafted:

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

This allows the mapper to tag the shared grounds as landuse=school, and
place the separate schools as nodes or buildings tagged with
amenity=school within.


This approach appears to be used quite a lot in France. One example:

https://www.openstreetmap.org/way/619185410

As you can see, Carto-OSM refuses to render landuse=school for now:

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


The French OpenStreetMap rendering meanwhile does render it:

https://tile.openstreetmap.fr/?layers=BFF=18=48.94156=2.36763


Effectively, this means French mappers utilize landuse=school, while the
rest won't for lack of documentation and progress on the proposal.


# Proposal

I've encountered a number of cases where multiple institutions related
to education share a single campus or area. I'm missing a suitable tag
for shared grounds or campuses (which often have their own name).

A common example that is gaining popularity in the Netherlands is having
amenity=kindergarten and amenity=school share a building and grounds.

Another example is amenity=university sharing a campus with
amenity=college and amenity=research_institute. All distinct educational
entities on a single named campus.

For the former example landuse=school seems suitable, but for the latter
a more generic landuse seems desirable.

What I want to propose is a landuse=education that can be taken as the
most generic form of landuse for educational purposes. This tag is
already in use (~500). Here, landuse=education will be similar to how
landuse=religious is used for grounds that house multiple
amenity=place_of_worship. It can be used for a range for educational
amenities, such as school, college, and university.

Then, landuse=school (~5000 in use) can be seen as a more specific form
of landuse=education.

Would such a proposal help move this issue forward? Anything that is
missing or glaringly wrong? I'll write up the proposal (subsuming the
current landuse=school proposal) and documentation if there is enough
support for this.

Kind regards,

Jeroen Hoek

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

Re: [Tagging] Tools and mass-retagging

[Jeroen Hoek]

On 08-06-18 13:37, Leo Gaspard wrote:

  * for all objects with natural=wood, add landcover=trees
  * for all objects with landuse=forest, add landcover=trees


Why not consider documenting that natural=wood and landuse=forest imply 
landcover=trees instead? It seems like a sensible default (similar to 
how access=yes is the default for access to generic highways such as 
highway=unclassified). Any exceptions can be explicitly mapped.


This is similar to how landuse=grass (when used to indicate an area that 
is used to grow grass) would imply landcover=grass.


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

Re: [Tagging] The endless debate about "landcover" as a top-level tag

[Jeroen Hoek]

On 07-06-18 00:51, Warin wrote:
> On 07/06/18 00:57, Martin Koppenhoefer wrote:
>>
>>
>> 2018-06-06 16:39 GMT+02:00 Christoph Hormann > <mailto:o...@imagico.de>>:
>> There probably is a strong majority among OSM mappers that
>> (rightfully)
>> think key semantics are irrelevant for the actual meaning of tags.
>>
>> What a tag in OSM means depends on what it is actually used for, not
>> what someone says the key used requires it to mean.
>
> The meanings of the key and value should make logical sense .. other
> wise it is a convoluted thing that is being thrust on all mappers and
> data consumers.
> The meaning should not migrate over time by the misuse of the tag by a
> number of mappers.

Not only that, but it hampers mappers in learning how to correctly use
them. If landuse consistently means "the primary use of the land", and
you learn about landuse=residential and landuse=railway through the
wiki, then a pattern emerges and you know what is going on when you
encounter landuse=commercial and landuse=retail.

But then you get to the local park and see that all large areas with
trees are tagged with landuse=forest (despite there not being an actual
forest), which you learn is how we tag an area covered in trees, and now
the system apparently has a bunch of exceptions you have to keep in mind.

At some point we end up with a database that requires our own private
arcana to understand — I fear that would create a gap between occasional
new mappers contributing through ID, and experienced mappers who can map
major infrastructural projects without breaking a single bus route, but
nothing in between.

Semantics matter a lot in a database that consists of tagged
geographical features.

Kind regards,

Jeroen Hoek

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

Re: [Tagging] The endless debate about "landcover" as a top-level tag

[Jeroen Hoek]

On 06-06-18 16:13, Mateusz Konieczny wrote:

For start - is there a well written proposal?

Is there a JOSM preset that people can manually enable?
 
Is there a well written issue proposing support in JOSM, iD, Vespucci 
(if already


Good points.

Perhaps I'll give it a go to write a concept for such a proposal. In 
addition to the landcover-proposal, the openstreetmap-carto issue on 
GirHub, and this email-thread, are there any other proposals and 
resources I should look at?


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

Re: [Tagging] The endless debate about "landcover" as a top-level tag

[Jeroen Hoek]

On 06-06-18 15:15, Martin Koppenhoefer wrote:
If I draw an area in iD and type “grass” in the search field I get a hit 
named “grass” with a generic green icon. Done (and I have added another 
landuse object).


The tagging question is not only about documentation and rendering, but 
also for a very significant part about editor and app presets.


Exactly. There is a very sensible landcover proposal that, in 
combination with a landuse=greenery (or a different suitable name for 
municipal/community/decorative greenery), makes a lot of sense from a 
semantic standpoint.


Only it won't gain traction because ID and JOSM don't provide presets, 
which they won't do until more people use them, which won't happen until 
openstreetmap-carto renders at least the generic landuse-tag and its 
most-used landcovers (trees, grass, and shrubs).


(Manual) retagging of existing areas also won't happen, because they 
would disappear from openstreetmap-carto, probably leading to reverts 
and a lot of irritation.


So it's a classic catch-22.

I'm not all that familiar with OSM politics (and I use that term without 
derision), but is there a way forward in such a situation?


I could imagine that a slimmed down proposal for a municipal greenery 
landuse, in combination with the more common landcover tags already 
proposed could be a good starting point, but without cooperation from 
the openstreetmap-carto developers and willingness from the ID and JOSM 
developers to incorporate new presets it probably won't progress beyond 
a permanent 'proposed' status.


Kind regards,

Jeroen Hoek

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