[Tagging] Door tag

[Kyle Hensel]

Hi, I’ve just noticed that https://wiki.osm.org/Key:door says “The door=* tag 
must be used in conjunction with the entrance=* tag on buildings”

This claim doesn’t reflect how the tag is actually used. Someone realized this 
and recently amended that statement to note that Simple Indoor Tagging is one 
exception. There are other exceptions though.

Can we change the wiki so that it says “An entrance tag” instead of “The 
entrance=* tag”?

“An entrance tag” would include tags like:

  *   entrance=*
  *   indoor=door
  *   amenity=loading_dock
  *   amenity=parking_entrance

Is this a controversial change or can the wiki page simply be updated?

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

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

[Jens Glad Balchen]

On 02.12.2022 13:31, Alex wrote:
Paths and ways along a road can be mapped separately in OSM, but those 
separate geometries cannot be identified as part of the road, or only 
with the significant effort of using geometric processing (which most 
applications can't perform). 


I strongly agree with the concept of tagging information that is hard or 
impossible to compute accurately or reliably. I want to emphasize that 
from the start since the objection has been raised in multiple 
discussions that something is theoretically computable. I would rather 
that we not obstruct valuable tagging because the same information could 
theoretically be computed by some brilliant algorithm not yet 
constructed and/or extremely detailed tagging, that in combination would 
require significantly more effort than just tagging the desired 
information in the first place.


Therefore, a sidepath concept using the tag "is_sidepath" as an 
additional tag on ways (in particular cycle ways or foot paths) is 
proposed to indicate whether a way is related/attendant to a road 
(i.e. adjacent and parallel to a road) or whether it runs 
independently/isolated without any relationship to a road. 
Furthermore, an extended set of sub-tags is proposed to allow to 
explicitly tag important road attributes on the sidepath itself.




_Mainly_, I have concerns about the concept of a cycle path or foot path 
being attendant to or a sidepath of another road.


In Norway, we no longer have cycle paths and foot paths. We have 
cycleways, footways and carriageways. It may seem like a small 
difference in terminology, but it makes a large difference as part of an 
overall mindset. Roads are roads, and different types of roads are 
simply meant for different types of travel.


To me, this proposal sounds similar to a hypothetical proposal that we 
start tagging roads that runs adjacent to railroads as 
"is_sideroad=yes". It makes very little sense to me to establish the 
railroad as the "primary" line of travel and the road as an "attendant" 
line of travel. Just because they are parallel does not mean there is a 
meaningful relation or hierarchy between them.


I'm concerned that this type of tagging establishes and codifies a 
hierarchy, a relative importance, and an implied dependence, that I 
don't see in many of the posted examples, and that I'm not aware exist 
in formal road structures.


An exception of course is if the road was specifically built to 
facilitate access to the railroad by non-rail means, and the road was 
tagged as such, it would make sense to relate it to the railroad it serves.


I know the term "sidepath" exists and is used, but I can't see that it 
is semantically different from cycle path, cycle road or cycleway, 
except for this rather vague property of somehow being an add-on to the 
"proper" road.


Can you provide any thoughts on how you see the "is_sidepath" 
relationship in principle?


_Additionally_, I'm curious about what you will do with the tag. I've 
read the use cases, but I don't fully understand them. Perhaps you can 
elaborate?


Rendering: How and why would a renderer treat a cycleway differently 
when is_sidepath=yes?


Routing: How does it help routers to know that a cycleway runs parallel 
to a carriageway? If the preference is to ride on cycleways, I assume 
the router will pick the cycleway regardless. If there is no preference, 
I assume the router will pick whichever line is shortest.

I see a value in being able to capture a name.

Data analysis: How is capturing the quality of a cycleway obstructed by 
the lack of an is_sidepath tag?


_Finally_, I agree that any use of is_sidepath or similar conceptual 
tagging, like in the railroad access road scenario, seems most valuable 
when it actually includes a direct reference to the other line. Simply 
knowing that there is a line out there that is parallel and adjacent to 
this line seems like very vague information. Duplicating some 
information from the related line seems a bit odd, because it still 
leaves no way to automatically tell which line we're trying to 
reference. But I guess it can be hard to implement a direct reference in 
practice, if the two ways don't have exactly matching line segments?


Cheers,

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

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

[Mateusz Konieczny via Tagging]

2 gru 2022, 20:50 od m...@nguyen.cincinnati.oh.us:

> Vào lúc 08:44 2022-12-02, Mateusz Konieczny via Tagging đã viết:
>
>> I have good news! There is preprocessing solution for large (nearly all?) 
>> simple cases,
>> written in Kotlin and is a part of StreetComplete.
>>
>> StreetComplete would be able to handle cases listed in its sidewalk detection
>> (used to skip sidewalk/cycleway quests in presence of nearby separately 
>> mapped sidewalk
>> - note that in new versions this quests are disabled by default as overlays
>> are intended to replace them)
>>
>> You can test how it works by finding place where roads have no sidewalk=* 
>> tags
>> and there are separately mapped sidewalks, navigate there in StreetComplete 
>> and
>> disable all quests except sidewalk/cycleway.
>>
>> You will get them on matching roads - except ones with detected nearby 
>> sidewalks.
>> You can also tweak filter rules to enable sidewalk and cycleway quest for 
>> all roads
>> to skip tag based filtering (which skips some roads unlikely to have 
>> cycleways
>> or sidewalks or already tagged with sidewalk* and cycleway* tags)
>>
>> This code would handle with slight modifications vast majority of cases.
>> Simplest one would be enlarging default buffer and other parameters.
>> Possible changes include taking into account cycleway*=separate tags and
>> sidewalk*=separate tags to search for larger distance if sidewalk was not 
>> found
>> and other obvious tweaks - all examples listed here would be handled.
>>
>
> Are you referring to this code? [1] A running time of O(n^3) is not 
> necessarily something others would consider a solution. Imagine a router 
> running this algorithm over a whole continent or planet when building the 
> routing graph. Yet it's also too sensitive to where a way happens to be 
> split. Either the footway or the roadway could be split at arbitrary points 
> for arbitrary reasons or no reason at all.
>
Yes, it is just a proof that it is at least partially doable - not something 
readily usable
for planet processing.
Still, makes me really dubious about applying this tagging everywhere - 
especially
if people applying it expect people editing highway tags or name tags or ref 
tags
to maintain this new tags.

> A more general algorithmic solution may be feasible, but it would probably 
> look much more like Skeletron [2], which conflates dual carriageways, or the 
> map matching algorithms in various routing engines, which are normally used 
> to align GPS traces to the road network. These approaches are overkill for 
> StreetComplete but may be a good fit for a routing engine. The edge cases in 
> [3] would require walking the routing graph to some extent. This is something 
> the Overpass API was originally designed to do, so it isn't inconcievable, 
> but it isn't purely a trigonometric problem.
>
+1

>> Yes, it will take some effort to write or adapt this code. But this proposal 
>> asks
>> mappers to manually preprocess millions of sidewalk sections.
>> Just currently marked footway=sidewalk (small part of all separately mapped 
>> sidewalks)
>> have 3 300 000+ sections.
>> Lets take optimistic 5s per section, initial tagging that alone would consume
>> 4695 hours of mapping (and also software costs to allow such efficient 
>> mapping!).
>> And likely 5s per way is very optimistic.
>> Add to that all separately mapped sidewalks without footway=sidewalk.
>>
>
> For what it's worth, this would be a similar scope of work as adding name=* 
> to each of the sidewalk ways, just as with dual carriageways. Mappers in some 
> cities are already systematically adding name=* to sidewalk ways, but it 
> hasn't really caught on globally, maybe because of how it clutters a typical 
> map. (But a renderer could simply avoid labeling footway=sidewalk.)
>
I would be also against this tagging style for similar reasons. Though at least 
it has
lower duplication and reclassifying highway=* way (not an unusual activity!)
is not resulting in pointless drudgery.

> Inevitably, there will be unhandled edge cases regardless of the algorithm. 
> Maybe a compromise would be to treat is_sidepath:of=* as an override for 
> difficult cases only, similar to name:pronunciation=*. The benefit over 
> name=* is that nothing changes for a renderer unless they opt into processing 
> the new key.
>
That would work for me - but this difficult cases should be identified.
I expect that relations may be needed for some, and this proposed tags will not
be sufficient in especially pathological ones (for example where road splits in 
multiple
named in the same way).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

[Minh Nguyen]

Vào lúc 07:54 2022-12-02, Tobias Knerr đã viết:

On 02.12.22 15:02 Mateusz Konieczny wrote:

If it is second case of preprocessing being impossible -
why do massive duplication and ask to duplicate ref value
AND name value AND highway value?


The duplication-free solution of referencing the road's way ID as 
is_sidepath:of = w4087515 is going meet some resistance from people 
pointing out the need for, and current lack of, editor support to make 
such values usable.


To clarify, the proposal calls for is_sidepath:of=* to be set to a road 
classification consistent with highway=*. It uses the combination of 
is_sidepath:of=*, is_sidepath:of:name=*, and is_sidepath:of:ref=* to 
unambiguously^H^H^H^H less ambiguously identify the nearby roadway. This 
is similar to the street:name=* key that mappers in a few cities have 
been using, but with the added benefit of resolving ambiguity when there 
are similarly named streets running parallel. (Is this a big enough 
problem to require the full set of tags?)


If the proposal had called for is_sidepath:of=* to refer to another way 
by its ID, I think we'd be howling about how way IDs are unstable and 
that we've reinvented relation membership, but in the inverse direction.


--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

[Minh Nguyen]

Vào lúc 08:44 2022-12-02, Mateusz Konieczny via Tagging đã viết:
I have good news! There is preprocessing solution for large (nearly 
all?) simple cases,

written in Kotlin and is a part of StreetComplete.

StreetComplete would be able to handle cases listed in its sidewalk 
detection
(used to skip sidewalk/cycleway quests in presence of nearby separately 
mapped sidewalk

- note that in new versions this quests are disabled by default as overlays
are intended to replace them)

You can test how it works by finding place where roads have no 
sidewalk=* tags
and there are separately mapped sidewalks, navigate there in 
StreetComplete and

disable all quests except sidewalk/cycleway.

You will get them on matching roads - except ones with detected nearby 
sidewalks.
You can also tweak filter rules to enable sidewalk and cycleway quest 
for all roads
to skip tag based filtering (which skips some roads unlikely to have 
cycleways

or sidewalks or already tagged with sidewalk* and cycleway* tags)

This code would handle with slight modifications vast majority of cases.
Simplest one would be enlarging default buffer and other parameters.
Possible changes include taking into account cycleway*=separate tags and
sidewalk*=separate tags to search for larger distance if sidewalk was 
not found

and other obvious tweaks - all examples listed here would be handled.


Are you referring to this code? [1] A running time of O(n^3) is not 
necessarily something others would consider a solution. Imagine a router 
running this algorithm over a whole continent or planet when building 
the routing graph. Yet it's also too sensitive to where a way happens to 
be split. Either the footway or the roadway could be split at arbitrary 
points for arbitrary reasons or no reason at all.


A more general algorithmic solution may be feasible, but it would 
probably look much more like Skeletron [2], which conflates dual 
carriageways, or the map matching algorithms in various routing engines, 
which are normally used to align GPS traces to the road network. These 
approaches are overkill for StreetComplete but may be a good fit for a 
routing engine. The edge cases in [3] would require walking the routing 
graph to some extent. This is something the Overpass API was originally 
designed to do, so it isn't inconcievable, but it isn't purely a 
trigonometric problem.


Yes, it will take some effort to write or adapt this code. But this 
proposal asks

mappers to manually preprocess millions of sidewalk sections.
Just currently marked footway=sidewalk (small part of all separately 
mapped sidewalks)

have 3 300 000+ sections.
Lets take optimistic 5s per section, initial tagging that alone would 
consume
4695 hours of mapping (and also software costs to allow such efficient 
mapping!).

And likely 5s per way is very optimistic.
Add to that all separately mapped sidewalks without footway=sidewalk.


For what it's worth, this would be a similar scope of work as adding 
name=* to each of the sidewalk ways, just as with dual carriageways. 
Mappers in some cities are already systematically adding name=* to 
sidewalk ways, but it hasn't really caught on globally, maybe because of 
how it clutters a typical map. (But a renderer could simply avoid 
labeling footway=sidewalk.)


Inevitably, there will be unhandled edge cases regardless of the 
algorithm. Maybe a compromise would be to treat is_sidepath:of=* as an 
override for difficult cases only, similar to name:pronunciation=*. The 
benefit over name=* is that nothing changes for a renderer unless they 
opt into processing the new key.


[1] 


[2] https://github.com/migurski/Skeletron/
[3] 



--
m...@nguyen.cincinnati.oh.us



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

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

[Mateusz Konieczny via Tagging]

2 gru 2022, 16:54 od o...@tobias-knerr.de:

> On 02.12.22 15:02 Mateusz Konieczny wrote:
>
>> Or is it justifiable because it is outright impossible to do reliably
>> with automatic preprocessing?
>>
>
> I would say that's the reason. Of course, it's hard to prove that something 
> is impossible. But so far no one has built a working solution for inferring 
> this information where it isn't explicitly mapped.
>
>> If yes, can you give examples where it would be beneficial
>> and explicitly ask to introduce such tagging solely in
>> cases where preprocessing is doomed to fail?
>>
>
> Given the current lack of working preprocessing solutions for even the easier 
> situations you've linked to, I'm not sure it's easy to tell where the 
> dividing between "solvable" and "unsolvable" is. It would also have to be 
> defined and explained in such a manner that mappers (and editing tools like 
> StreetComplete who might some day ask users to fill this in) can easily 
> understand where it is or isn't needed.
>
I have good news! There is preprocessing solution for large (nearly all?) 
simple cases,
written in Kotlin and is a part of StreetComplete.

StreetComplete would be able to handle cases listed in its sidewalk detection
(used to skip sidewalk/cycleway quests in presence of nearby separately mapped 
sidewalk
- note that in new versions this quests are disabled by default as overlays
are intended to replace them)

You can test how it works by finding place where roads have no sidewalk=* tags
and there are separately mapped sidewalks, navigate there in StreetComplete and
disable all quests except sidewalk/cycleway.

You will get them on matching roads - except ones with detected nearby 
sidewalks.
You can also tweak filter rules to enable sidewalk and cycleway quest for all 
roads
to skip tag based filtering (which skips some roads unlikely to have cycleways
or sidewalks or already tagged with sidewalk* and cycleway* tags)

This code would handle with slight modifications vast majority of cases.
Simplest one would be enlarging default buffer and other parameters.
Possible changes include taking into account cycleway*=separate tags and 
sidewalk*=separate tags to search for larger distance if sidewalk was not found
and other obvious tweaks - all examples listed here would be handled.

Yes, it will take some effort to write or adapt this code. But this proposal 
asks
mappers to manually preprocess millions of sidewalk sections.
Just currently marked footway=sidewalk (small part of all separately mapped 
sidewalks)
have 3 300 000+ sections.
Lets take optimistic 5s per section, initial tagging that alone would consume
4695 hours of mapping (and also software costs to allow such efficient 
mapping!).
And likely 5s per way is very optimistic.
Add to that all separately mapped sidewalks without footway=sidewalk.

And that is a small part. The worst part is that any time you update
highway=* value or name or ref there is an added drudgery to update this
on sidewalks.


>> If it is second case of preprocessing being impossible -
>> why do massive duplication and ask to duplicate ref value
>> AND name value AND highway value?
>>
>
> The duplication-free solution of referencing the road's way ID as 
> is_sidepath:of = w4087515 is going meet some resistance from people pointing 
> out the need for, and current lack of, editor support to make such values 
> usable.
>
> (Not from me, though, I'd love that approach and have dozens of ideas for 
> other places where it would be helpful. :))
>
> ___
> 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] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

[Tobias Knerr]

On 02.12.22 15:02 Mateusz Konieczny wrote:

Or is it justifiable because it is outright impossible to do reliably
with automatic preprocessing?


I would say that's the reason. Of course, it's hard to prove that 
something is impossible. But so far no one has built a working solution 
for inferring this information where it isn't explicitly mapped.



If yes, can you give examples where it would be beneficial
and explicitly ask to introduce such tagging solely in
cases where preprocessing is doomed to fail?


Given the current lack of working preprocessing solutions for even the 
easier situations you've linked to, I'm not sure it's easy to tell where 
the dividing between "solvable" and "unsolvable" is. It would also have 
to be defined and explained in such a manner that mappers (and editing 
tools like StreetComplete who might some day ask users to fill this in) 
can easily understand where it is or isn't needed.



If it is second case of preprocessing being impossible -
why do massive duplication and ask to duplicate ref value
AND name value AND highway value?


The duplication-free solution of referencing the road's way ID as 
is_sidepath:of = w4087515 is going meet some resistance from people 
pointing out the need for, and current lack of, editor support to make 
such values usable.


(Not from me, though, I'd love that approach and have dozens of ideas 
for other places where it would be helpful. :))


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

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

[Mateusz Konieczny via Tagging]

"or only with the significant effort of using geometric  processing
(which most applications can't perform)"

why doing it manually would be preferable?

Is it repeating mistake of adding pointless work for mappers
because it "causes extra preprocessing for routing software."?
And valuing time of mappers as worth nothing?
(PTv2 asks mappers to do something derivable from highway=bus_stop
location and roads within bus relation, massive amount of work
of mappers wasted to do preprocessing manually
https://wiki.openstreetmap.org/w/index.php?oldid=625726 )

Why https://www.openstreetmap.org/way/24034881
needs to be preprocessed manually?
The same for https://www.openstreetmap.org/way/788729
https://www.openstreetmap.org/way/118390194
https://www.openstreetmap.org/way/233305340 
https://www.openstreetmap.org/way/119380508
(all examples from the proposal)

Or is it justifiable because it is outright impossible to do reliably
with automatic preprocessing?
(that is the justification for
https://wiki.openstreetmap.org/wiki/Tag:dual_carriageway%3Dyes
)
If yes, can you give examples where it would be beneficial
and explicitly ask to introduce such tagging solely in
cases where preprocessing is doomed to fail?

If it is second case of preprocessing being impossible -
why do massive duplication and ask to duplicate ref value 
AND name value AND highway value?



Also, I think that
https://www.openstreetmap.org/way/119380508 is clearly a sidewalk
of that road.

2 gru 2022, 13:31 od supap...@riseup.net:

>
>
> Paths and ways along a road can be mapped separately in OSM, but  those 
> separate geometries cannot be identified as part of the  road, or only 
> with the significant effort of using geometric  processing (which most 
> applications can't perform). However, the  information whether a path is 
> attendant to a road or not is  important for many use cases and can offer 
> various advantages.
>  
>  Therefore, a sidepath concept using the tag "is_sidepath" as an  
> additional tag on ways (in particular cycle ways or foot paths) is  
> proposed to indicate whether a way is related/attendant to a road  (i.e. 
> adjacent and parallel to a road) or whether it runs  
> independently/isolated without any relationship to a road.  Furthermore, 
> an extended set of sub-tags is proposed to allow to  explicitly tag 
> important road attributes on the sidepath itself.
>  
>  > https://wiki.openstreetmap.org/wiki/Proposed_features/Key:is_sidepath
>  
>  You can discuss this proposal on its Wiki Talk page or here.
>
>
>
> Best, Alex
>
>

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

[Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

[Alex]

Paths and ways along a road can be mapped separately in OSM, but those 
separate geometries cannot be identified as part of the road, or only 
with the significant effort of using geometric processing (which most 
applications can't perform). However, the information whether a path is 
attendant to a road or not is important for many use cases and can offer 
various advantages.


Therefore, a sidepath concept using the tag "is_sidepath" as an 
additional tag on ways (in particular cycle ways or foot paths) is 
proposed to indicate whether a way is related/attendant to a road (i.e. 
adjacent and parallel to a road) or whether it runs 
independently/isolated without any relationship to a road. Furthermore, 
an extended set of sub-tags is proposed to allow to explicitly tag 
important road attributes on the sidepath itself.


https://wiki.openstreetmap.org/wiki/Proposed_features/Key:is_sidepath

You can discuss this proposal on its Wiki Talk page or here.

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