Re: [Tagging] Tagging a site with "Luxury Lodges"

[Martin Koppenhoefer]

sent from a phone

> On 23. May 2019, at 00:27, Joseph Eisenberg  
> wrote:
> 
> It’s advertised just like a normal residential area, and claims to have won a 
> “Warick village of the year” award. So I would use landuse=residential for 
> the area, and building=house for each structure.


the village of the year price was won by the poor village where this holiday 
site landed, who knows if they would still have won with the lodge park already 
in place ;-)

While they might be called „house“, why not „building=lodge“? The fact they are 
poorly insulated, prefabricated wooden single floor structures is better 
reflected by that word.

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

Re: [Tagging] A simple survey and proposal about tagging cram schools

[石野貴之]

2019年5月23日(木) 4:22 Jmapb :

>
> Hi! Just in case you missed it, we had brief and inconclusive
> discussions of these earlier this year:
>
> https://lists.openstreetmap.org/pipermail/tagging/2019-January/042561.html
> https://lists.openstreetmap.org/pipermail/tagging/2019-February/042983.html
> https://lists.openstreetmap.org/pipermail/tagging/2019-March/043617.html
>
>
 Thank you for the information.
My main idea is almost identical with what is presented in the last thread.
I have two reasons to express this idea in my diary.
1. OSM Japan community is not so aware of the current situation and issues
of tagging educational institutions outside of school.
I wrote a Japanese diary first to pose a problem to our community and asked
the readers to give comments.
https://www.openstreetmap.org/user/yumean1119/diary/364501
I thought it would be great to have opinions from all over the world.
That's why I posted a diary in English too.
https://www.openstreetmap.org/user/yumean1119/diary/364867

2. My goal is to organize tagging schemes on various types of educational
institutions, not only on cram school or tutoring school.
I have been worried about the slow progress in discussing a simple tagging
scheme(education=*)
https://wiki.openstreetmap.org/wiki/Proposed_Features/Education_Reform_Alternative
and I felt the need to decide our policy on using education=* tags before
we go to the next step.(e.g. deprecating amenity=school;university and so
on)

Takayuki Ishino
yumean1...@gmail.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Graeme Fitzpatrick]

On Thu, 23 May 2019 at 09:10, marc marc  wrote:

>
> I may have missed the last iD update announcement announcing this,
> what this transparent or discovered by chance?
>

This one, which includes heaps of changes!?

https://github.com/openstreetmap/openstreetmap-website/pull/2231

Thanks

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

Re: [Tagging] Definition of Sport

[marc marc]

Le 23.05.19 à 01:26, Warin a écrit :
> A) A physical competition played according to rules.
> 
> B) As for A) but includes practising for the sport
> 
> c) as for B) but includes non competitive physical activity.
> 
> Thoughts? 
i like C but without the "with rules" included via A :)
there is no rule defining how to swim as a hobby,
swim like a dog if you want, it's still swimming
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - camp_site=camp_pitch

[marc marc]

sumary :
imho, this thread is trying to solve all issues in one shoot,
and this nearly always fail.
it seems better to cut this into several parts from the simplest to the 
most complicated (retag camp_site=* objects that have already a more 
suitable tags such as toilets, depreciated one by one the most 
problematic values of camp_site) in order to clarify the final solution.
that's what I proposed on the french-speaking list, no one is against 
it, no public reaction, but taginfo shows that there are people
working to improve the situation

Le 22.05.19 à 03:26, Tod Fitch a écrit :
 > If the tourism=camp_site has only one place to camp:
 > tourism=camp_site
 > camp_site=camp_pitch
 > camp_pitch:type=tent
 > camp_pitch:fire=ring

that doesn't solve the double (hidjack) meaning of camp_site
and to avoid unneeded namespace and use as often existing tags,
I prefer somethink like :
tourism=camp_site
camp_site=basic/standard/serviced/deluxe
camp_pitch:count=1 or camp_pitch=1
tents=yes/only
fireplace=yes/ring

 > https://wiki.openstreetmap.org/wiki/Proposed_features/Key:camp_pitch

this propal over-use the namespace
for ex drinking_water=yes/no is enought, no namespace needed

Le 22.05.19 à 06:09, Tod Fitch a écrit :
 > a site with only one place for tent/caravan
 > list the detailed characteristics (table, fire ring, etc.).

I don't understand the issue.
just add the detailed characteristics to tourism=camp_site
like it's already done for a lot of them.
and add camp_pitch:count=1 or camp_pitch=1

Le 22.05.19 à 06:09, Tod Fitch a écrit :
 > What we’d call a “campground” is apparently called a “campsite” in
 > British English and somehow turned into “camp site” in OSM. And what
 > we’d call an individual place within a campground would be “camp site”
 > but is apparently a “pitch” in BE.

it's probably a good idea to inform about the risk of confusion
on the wiki

 > camp_site=pitch [5] was not well accepted by people on these mailing 
lists because “pitch” is more associated with fields for sports.

I have review 100+ of them yesterday, I have found 2 usecases :
- some are a camp_pitch in camp_site that have several camp_pitch". 
Those can be fixed with tourism=camp_pitch (not because I like this,
but because fixing one issue (avoid conflit with tourism=camp_site + 
camp_site=basic/standard/serviced/deluxe) is better than fixing none
of them. camp_pitch=yes is also a tmp fix due you dislike 
tourism=camp_pitch, or part=camp_pitch
- some are a "part" of camp_site grouped because of a common caracts 
like a camp_site tents=yes caravans=yes with a part for tents=yes and a 
part for caravans=yes
all tag/value currently in use are imho wrong. I have fixed those with 
tourism=camp_pitch the existing least bad solution we currently have in 
use. camp_pitch=many or part=yes may also be a tmp fix to find those later.

that said, the problem of camp_pitch is general, values are drowned with 
item that have other more suitable tags. somes examples found :
camp_site=entrance on a node of the outer -> entrance=yes
camp_site=toilets -> amenity=toilets (sometime with access=customers)
camp_site=shower -> amenity=shower (sometime with access=customers)
camp_site=caravan -> caravans=yes/designated

 > Proposed for a pitch within a campsite: camp_site:part=camp_pitch

I agree with that, but some find it too long.
so maybe it's better to cut issues in 3 :
- fix camp_site= value when a better tag exist (toilets, shower, 
entrance, ...)
- move camp_site=pitch camp_site=camp_pitch out of camp_site=* to solve 
the double meaning of this tag (a camp_site with one-only camp_pitch <> 
a camp_pitch in a camp_site with severals camp_pitch). we can tmp use 
tourism=camp_pitch or camp_pitch=yes or whatever to move out the 
approved tourism=camp_site camp_site=* tag linking.
- find what the best schema could be for : a camp_pitch in a whole camp, 
a part of a whole camp used to add a subtag for this part

Le 22.05.19 à 10:02, Martin Koppenhoefer a écrit :
 > the sum of all building:parts make up the whole building

you may add a part just to describe that a caract of a part
that the usecase I have found by looking at the current usage

Le 22.05.19 à 10:02, Martin Koppenhoefer a écrit :
 > If for some reason we don’t want to use the tourism key for these,
 > the tag could still be much more simple, e.g. camping=pitch

so camping 'll become a main tag with only one value ? hum
and that doesn't solve how to tag a part that isn't a camp_pitch
or you also add camping=part ? that's not so far from part=yes
inside a camping
and imho it won't take long to see camping=site =toilets and so on

Le 23.05.19 à 00:19, Graeme Fitzpatrick a écrit :
 > then for each site

so no main tag/value at all ? that avoid any bad tag/value :)
but it is a radical change to have objects that only have subtags
that exist elsewhere and no main tag describing what the object.
practical problem: counting or render or finding those objects
becomes very complicated since 

[Tagging] Definition of Sport

[Warin]

From the talk here on juggling and private conversations with others 
there are various 'definitions' of the key 'sport' in use by OSM mappers.


There are various definitions of the word sport in various dictionaries.

The Macquarie (Australian):

List some 20 various meanings/definitions .. e.g.

16. to have or ware, especially ostentatiously or proudly

12. Biology. an animal or plant, or part of a plant that shows an 
unusual  or singular deviation from  normal or parent type; a mutation.


Of more relevance here

1. an activity pursued for exercise or pleasure, usually requiring some 
degree of physical prowess


2. a particular form of such activity, such as racing, cricket, tennis, 
golf, bowling, wrestling, boxing, etc.


The Cambridge dictionary: 1) a game 
, competition 
, or 
activity  
needing  
physical  
effort  and 
skill  that 
is played  or 
done according 
 to rules 
, for 
enjoyment 
 and/or 
as a job : 2) 
all types  of 
physical  
activity  
that people  
do to keep  
healthy  or 
for enjoyment 
:


---

So there are various definitions. Which one should OSM use?

I'll place my rough definitions here

A) A physical competition played according to rules.

B) As for A) but includes practising for the sport

c) as for B) but includes non competitive physical activity.

Thoughts? I don't want to get into individual cases, but an overall 
concept of this definition for the key 'sport'.


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

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

[Michael Booth]

That explains why I saw highway=footway being added to a platform in a 
changeset today...


If adding highway=footway is such a good idea then let's have a 
discussion and get it added to every platform, rather than this fake 
"upgrade" tag feature in iD.


Maybe routers should treat platforms as routable on foot by default?

Another issue is that any platform mapped as an area will now render as 
a footway area, see: https://www.openstreetmap.org/way/252199901


On 22/05/2019 23:23, Michael Reichert wrote:

Hi,

I discovered today that iD suggests to add highway=footway to
railway/public_transport=platform objects as part of its new validation
rules. On a GitHub ticket I found, Quincy Morgan explained it that way [1]:

Features with these tags are expected to be part of the pedestrian network, but 
without highway tags it is more difficult for routers (and iD's validation) to 
support them. iD should add highway=footway automatically and recommend 
upgrading features lacking this tag.

I disagree with that.

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

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

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

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

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

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

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

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

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

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

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

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

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

Japan:
typeptr   ptr pt+f 

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

[Michael Booth]

That explains why I saw highway=footway being added to a platform in a 
changeset today...


If adding highway=footway is such a good idea then let's have a 
discussion and get it added to every platform, rather than this fake 
"upgrade" tag feature in iD.


Maybe routers should treat platforms as routable on foot by default?

Another issue is that any platform mapped as an area will now render as 
a footway area, see: https://www.openstreetmap.org/way/252199901


On 22/05/2019 23:23, Michael Reichert wrote:

Hi,

I discovered today that iD suggests to add highway=footway to
railway/public_transport=platform objects as part of its new validation
rules. On a GitHub ticket I found, Quincy Morgan explained it that way [1]:

Features with these tags are expected to be part of the pedestrian network, but 
without highway tags it is more difficult for routers (and iD's validation) to 
support them. iD should add highway=footway automatically and recommend 
upgrading features lacking this tag.

I disagree with that.

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

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

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

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

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

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

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

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

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

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

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

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

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

Japan:
typeptr   ptr pt+f 

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

[Dave F via Tagging]

They've (just quincylvania?) got their logic backwards. A platform is, 
by default, accessible by people. It's what they are designed for in the 
real world.


I find it strange/worrying he makes these far reaching decisions 
unilaterally (unless there's other hidden discussions not linked to in 
#6042


On 22/05/2019 23:23, Michael Reichert wrote:

Hi,

I discovered today that iD suggests to add highway=footway to
railway/public_transport=platform objects as part of its new validation
rules. On a GitHub ticket I found, Quincy Morgan explained it that way [1]:

Features with these tags are expected to be part of the pedestrian network, but 
without highway tags it is more difficult for routers (and iD's validation) to 
support them. iD should add highway=footway automatically and recommend 
upgrading features lacking this tag.

I disagree with that.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[marc marc]

Le 23.05.19 à 00:23, Michael Reichert a écrit :
> What is your opinion on this issue?

Thanks for the so documented message.
I didn't read all numbers but indeed, some plateform aren't
a footway
some are a path
some of indoor feature (more like a room=corridor)
it could be a good idea to improve the routing in those case,
but not with an easy/wrong assertion "all plateform mean X access"
some may get a highway tag to avoid breaking the highway network
some have a highway through the plateform area (that the issue of having 
a linear+area network)

I may have missed the last iD update announcement announcing this,
what this transparent or discovered by chance?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - camp_site=camp_pitch

[Joseph Eisenberg]

While “campsite” is confusing for Americans (like myself) and Aussie’s, it
is the correct British English term for what we call a “campground”, and a
(camping) “pitch” is what we call a “campsite” or “tent site”.

Hence the value should have include something like “pitch”.

I suppose this is fair payback for Americans having designed most websites
and programming languages without regard for  British spelling or word
definitions. :-)

Joseph

On Thu, May 23, 2019 at 7:21 AM Graeme Fitzpatrick 
wrote:

>
> On Wed, 22 May 2019 at 14:12, Tod Fitch  wrote:
>
>> Please excuse possible Americanisms. What we’d call a “campground” is
>> apparently called a “campsite” in British English and somehow turned into
>> “camp site” in OSM. And what we’d call an individual place within a
>> campground would be “camp site” but is apparently a “pitch” in BE.
>>
>
> & from an Aussie point of view, that term is just as confusing as it
> apparently is for you!
>
> I've been going camping for over 40 years now (!) & I've *never* heard
> the term camp-pitch, before it's come up in this discussion. Yes, you
> "pitch camp" or "pitch a tent", but you do it on a camp site in a camping
> (or camp) ground, not on a camp pitch.
>
> Marked & allocated spots in a caravan park, or camp/ing ground are "sites"
> eg we are booked into Site 86 in Whichever Caravan Park this weekend.
>
> Personally, I'd prefer to get rid of the camp_pitch idea altogether & just
> use our established tags
>
> tourism=camp_site (or =caravan_site) + name=, address= etc
> with "all of park" details
> toilets=yes/no/fee
> shower=yes/no/fee - maybe hot/cold?
>
> then for each site
>
> ref=# / SIte #
> usage=caravan/camper_trailer/tent/walk_in (some sites are reserved for
> large motorhomes, some are tent only etc)
> vehicle_access=yes/no (can you actually drive onto the site - some you
> have to park in the car park & carry your tent & all your gear to the
> actual site)
> fire=yes/no/ring/off_ground
> power=yes/no
> water=yes/no
> sullage=yes/no
> surface=grass/sand/gravel/concrete
> slab=yes/no
> etc
>
> Thanks
>
> Graeme
> ___
> 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] Opening hours syntax for non Gregorian calendar

[Graeme Fitzpatrick]

On Thu, 23 May 2019 at 00:10, Simon Poole  wrote:

> (I suppose there might be a use case for "RH", religious holidays, but
> lets don't add baggage before somebody actually asks for it :-)).
>

But what are Christmas & Easter if they're not religious holidays? :-)

Thanks

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

Re: [Tagging] Feature Proposal - RFC - changing table - self referencing description

[Warin]

https://wiki.openstreetmap.org/wiki/Proposed_features/changing_table

The present definition for the tag 'changing_table' is "A tag for 
tagging changing tables".



This is a 'self referencing description'. One way of 
testing/demonstrating this is to remove any words in the description 
that are present in the source.


This would make the description "A for " ... and that demonstrates the 
failing of a self referencing description, they add no real information 
to aid a person who does not know what is mean by the tag 'changing_table'.


-

So what is a better description for OSM use? The tag is to be used to 
indicate the presence of an aid to replacing babies nappies, so start 
with that in a broad sense?


"an aid to replacing clothing"

That could be applied to dolls, animals etc .. so make it for humans, 
usually babies?



"an aid to replacing human, usually babies, clothing"

Clothing might be too general, so reduce it to nappies/diaper?


"an aid to replacing human, usually babies, nappies/diaper"








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

Re: [Tagging] Feature Proposal - RFC - changing table

[marc marc]

thanks, it look like fine.

Le 22.05.19 à 14:44, Valor Naram a écrit :
> I corrected the language issue and also moved the text in the "Tagging" 
> section to the "Rationale" section as suggested by Marc
> 
> Thank you both
> 
> Best regards
> 
> Sören alias Valor Naram
> 
> 
>  Original Message 
> Subject: Re: [Tagging] Feature Proposal - RFC - changing table
> From: Michael Brandtner via Tagging
> To: tagging@openstreetmap.org
> CC: Michael Brandtner
> 
> 
> I think that this is a language issue and the hallway (German
> "Flur") is meant, not the floor.
> 
> Am Dienstag, 21. Mai 2019, 03:11:32 MESZ hat marc marc
>  Folgendes geschrieben:
> 
> 
> Hello,
> 
>  > https://wiki.openstreetmap.org/wiki/Proposed_features/changing_table
> 
> questions / minor suggestions :
> 
> in changing_table:location=room what's the usecase of :
> "or the floor to the toilets" ? maybe just drop it.
> if someone wants to put their child on the floor, I don't see how
> we could describe that this floor is adapted but not this other one
> 
> the first sentence of the tagging paragraph is about the rational (why
> some other existing tag doesn't fit the need),
> drop or move it to the rational paragraph
> 
> Regards,
> Marc
> 
> ___
> 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] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Mateusz Konieczny]

23 May 2019, 00:23 by osm...@michreichert.de:

> (3) highway=footway is added to ways which are clearly tagged as area
> using area=yes. Many routers route along the edges of areas but that's
> more a bug and workaround than a good feature. A highway=footway area is
> mapped as either area:highway=footway, not as highway=footway +
> area=yes. iD recommends bad tagging. highway=service and
> highway=pedestrian are the only tags where area=yes is widely accepted,
> isn't it? There is no linear footway along the edge of an platform but
> the whole platform polygon is the feature.
>
> I pointed out these reasons (not the numbers – I run my counting
> programme while preparing this email) today but my request rejected.
>
> What is your opinion on this issue? Feel free to reply to this email or
> comment at > https://github.com/openstreetmap/iD/issues/6409 
> 
>
I always though that platform should not interupt footways, but platform itself
has no need for footway tag on its area

See for example
https://www.openstreetmap.org/?mlat=50.06524=19.95230#map=19/50.06524/19.95230
https://www.openstreetmap.org/way/234100234#map=19/50.06524/19.95277
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging a site with "Luxury Lodges"

[Joseph Eisenberg]

Looking at the website, it appears that you buy a plot of land from the
developer and then pick out a “manufactured home”, a house built in a Works
(factory) and then delivered to the site in 2 pieces. The “luxury” part is
very debatable, but I agree that these are a step up from a static_caravan:
they are more than twice as wide as a trailer and look to have a permanent
foundation, no wheels.

But the only thing luxury about these is the price. 190,000 pounds for 1000
square feet?!

It’s advertised just like a normal residential area, and claims to have won
a “Warick village of the year” award. So I would use landuse=residential
for the area, and building=house for each structure.

Joseph

On Thu, May 23, 2019 at 12:07 AM Mateusz Konieczny 
wrote:

> 22 May 2019, 16:45 by tagging@openstreetmap.org:
>
> I hesitate to raise my simple question in such an expert forum, but I want
> to tag correctly and cannot find the guidance I need in the Wiki.
>
> Feel free to ask any questions how things should be tagged!
>
> How should I tag Willow Park in Salford Priors, near Evesham (UK)?
> https://www.openstreetmap.org/way/135928544
>
> Their website http://willowparkluxurylodges.co.uk/ talks of luxury lodges
> in the countryside.  You cannot live there permanently, because the site
> is only open for 11 months of the year.  Instead, you buy a “lodge” on
> the site and use it for holidays and weekends away (from the dirty, noisy
> city, where you live, I assume).
>
> Is it actually similar to buying a house? In that case it sounds to me
> like a residential area,
> used as a secondary vacation home, not some hotel/caravan site and I would
> use landuse=residential.
>
> Or is this "buying" a legal loophole and you may arrive, "buy" lodge, use
> it for two weeks and "sell" it,
> with all this "buying" and "selling" being a legal fiction?
>
> In that case it would be probably an expensive hotel.
>
> ___
> 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] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Michael Reichert]

Hi,

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

I disagree with that.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [Tagging] Feature Proposal - Voting - camp_site=camp_pitch

[Graeme Fitzpatrick]

On Wed, 22 May 2019 at 14:12, Tod Fitch  wrote:

> Please excuse possible Americanisms. What we’d call a “campground” is
> apparently called a “campsite” in British English and somehow turned into
> “camp site” in OSM. And what we’d call an individual place within a
> campground would be “camp site” but is apparently a “pitch” in BE.
>

& from an Aussie point of view, that term is just as confusing as it
apparently is for you!

I've been going camping for over 40 years now (!) & I've *never* heard the
term camp-pitch, before it's come up in this discussion. Yes, you "pitch
camp" or "pitch a tent", but you do it on a camp site in a camping (or
camp) ground, not on a camp pitch.

Marked & allocated spots in a caravan park, or camp/ing ground are "sites"
eg we are booked into Site 86 in Whichever Caravan Park this weekend.

Personally, I'd prefer to get rid of the camp_pitch idea altogether & just
use our established tags

tourism=camp_site (or =caravan_site) + name=, address= etc
with "all of park" details
toilets=yes/no/fee
shower=yes/no/fee - maybe hot/cold?

then for each site

ref=# / SIte #
usage=caravan/camper_trailer/tent/walk_in (some sites are reserved for
large motorhomes, some are tent only etc)
vehicle_access=yes/no (can you actually drive onto the site - some you have
to park in the car park & carry your tent & all your gear to the actual
site)
fire=yes/no/ring/off_ground
power=yes/no
water=yes/no
sullage=yes/no
surface=grass/sand/gravel/concrete
slab=yes/no
etc

Thanks

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

Re: [Tagging] A simple survey and proposal about tagging cram schools

[Jmapb]

On 5/22/2019 3:03 PM, 石野貴之 wrote:


Hello.
I have wanted to organize tagging schemes of educational institutions
outside school. I conducted a very simple survey and uploaded the
result and my opinion in
https://www.openstreetmap.org/user/yumean1119/diary/364867
.

I would be glad if you give me any comments.


Hi! Just in case you missed it, we had brief and inconclusive
discussions of these earlier this year:

https://lists.openstreetmap.org/pipermail/tagging/2019-January/042561.html
https://lists.openstreetmap.org/pipermail/tagging/2019-February/042983.html
https://lists.openstreetmap.org/pipermail/tagging/2019-March/043617.html

There are some other tagging suggestions mentioned in those threads that
you might want to add to your survey:
amenity=cram_school, amenity=tutoring, office=tutoring,
office=educational_institution, education=tutoring

The last one, education=tutoring, is the best IMO but hinges upon the
general acceptance of education=* as a valid tagging scheme, which is
uncertain at this point.

Jason


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

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Nick Bolten]

> crossing=traffic_signals
> crossing:markings=no

Ah, I see. Would you envision the only value for crossing:markings be "no",
or would it potentially have yes/no/{type}, where mappers use it at their
discretion - such as in this example?

On Mon, May 20, 2019 at 10:49 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 20. May 2019, at 17:17, Nick Bolten  wrote:
>
> > I would suggest to tag the exception, i.e. the absence of crossing
> markings where there is a pedestrian traffic light controlled crossing,
> with an additional property for the crossing node.
>
> I'm not following, could you give an example?
>
>
>
> crossing=traffic_signals
> crossing:markings=no
>
> 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

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Nick Bolten]

> The core of the issue seems to be that there are two conflicting
mindsets: Mapping "types" of crossings versus having a "construction kit"
of several tags which each describe one facet of the crossing.

I agree, this is the central issue behind the tags being non-orthogonal:
crossing=* implies the "type" of crossing whereas the values often describe
(or are interpreted as describing) a "construction kit". The crossing "is
a" type (unmarked, uncontrolled, traffic_signals) vs. "has a" properties
(markings, signals, etc).

I'm open to the idea of crossing:markings=yes/no/* rather than
crossing=marked/unmarked.

> If we want to have "types of crossings" at all, it would be highly
unexpected to ignore the presence of traffic signals for that purpose.
> And the crossing=* key clearly seems to be intended for mapping the
type of the crossing. That meaning is suggested by the name of the key
itself, not just the current set of values, so I believe it's
counter-intuitive to turn it into just one of several equally important
orthogonal keys.

I agree that deciding the "type" to be markings is semi-arbitrary and
acknowledge that many think concepts like signals or "controls" take
precedent. These two proposals could have gone with
crossing=traffic_signals/unsignaled + crossing:markings=yes/no/* and still
solve the core issues.

> So what I would probably do is mix the two approaches instead of going
for a conceptually pure implementation. Use
crossing=unmarked/marked/traffic_signals for a basic classification of the
crossing's type, and then add orthogonal subtags like crossing:island=*,
crossing:marking=* etc. as needed.

I tend to prefer least-resistance / compromise options, and this sounds
like it's in that direction. If I'm understanding it right, these would be
taggable:

crossing=unmarked/uncontrolled/traffic_signals/no
crossing:markings=yes/no/*
crossing:signals=yes/no/*

One downside to allowing both approaches is the amount of redundancy in
tagging crossings: not only do we tag both the node on the street and a way
(if available), we can be tagging something like crossing=traffic_signals
and crossing:signals=yes/no/*, crossing:markings=yes/no/*. Personally, I
would never map or consume crossing=traffic_signals because it's frequently
unknowable what the mapper intended, so we'd have a system of competing
standards. I would also be tempted to convert crossing=* into the
crossing:* namespace tags whenever possible, due to the many problems
listed on these proposals.

But, for the sake of having an option, what do others think about this
approach? New subtags for markings/signals, old tags still allowed?

On Wed, May 22, 2019 at 8:39 AM Tobias Knerr  wrote:

> On 08.05.19 01:30, Nick Bolten wrote:
> > Would it be fair to say you're suggesting something along the lines of
> > crossing:marking=*, where * can be yes, no, or a marking type? You make
> > a good point about the simplicity of avoiding a subtag for markings.
>
> Yes, this is pretty much what I'm suggesting. And I believe it would be
> an useful tag no matter whether we make crossing mapping fully
> orthogonal or just mostly orthogonal.
>
> Taking a step back to explain my thoughts on splitting off signals...
>
> The core of the issue seems to be that there are two conflicting
> mindsets: Mapping "types" of crossings versus having a "construction
> kit" of several tags which each describe one facet of the crossing.
>
> If we want to have "types of crossings" at all, it would be highly
> unexpected to ignore the presence of traffic signals for that purpose.
> And the crossing=* key clearly seems to be intended for mapping the type
> of the crossing. That meaning is suggested by the name of the key
> itself, not just the current set of values, so I believe it's
> counter-intuitive to turn it into just one of several equally important
> orthogonal keys.
>
> What else could we do with crossing=*? In theory, we could just get rid
> of it entirely, but realistically, that's not going to fly, and I'm not
> even sure if it would be desirable. People _do_ tend to mentally put
> things to categories, and describing the most common crossings with just
> one tag is certainly convenient.
>
> So what I would probably do is mix the two approaches instead of going
> for a conceptually pure implementation. Use
> crossing=unmarked/marked/traffic_signals
> for a basic classification of the crossing's type, and then add
> orthogonal subtags like crossing:island=*, crossing:marking=* etc. as
> needed. It lacks the elegance of full orthogonality, but covers all
> practical use cases.
>
> Tobias
>
> ___
> 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] A simple survey and proposal about tagging cram schools

[石野貴之]

Hello.
I have wanted to organize tagging schemes of educational institutions
outside school. I conducted a very simple survey and uploaded the result
and my opinion in
https://www.openstreetmap.org/user/yumean1119/diary/364867
.

I would be glad if you give me any comments.

Takayuki Ishino
yumean1...@gmail.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - juggling spot

[Martin Koppenhoefer]

sent from a phone

> On 22. May 2019, at 09:26, Pablo  wrote:
> 
> I don't know any spaces primarily used for juggling, bukers, scuba diving, 
> slack line, or other sport that don't need peculiar infrastructures. (Even 
> ski station are not primarily used for ski in summer). So why not use the tag 
> leisure = pitch sport=juggling?  And if needed adding another sport=whatever.


is there any „pitch“? What about
 leisure=spot

 Could be used for fishing as well (ok, they’re using leisure=fishing currently:
https://taginfo.openstreetmap.org/tags/leisure=fishing

There are also 4 juggling=spot and the word is not used as a value.
https://taginfo.openstreetmap.org/keys/juggling

sport=juggling sounds reasonable, if fishing and chess are sports.

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

Re: [Tagging] Feature Proposal - RFC - juggling spot

[Martin Koppenhoefer]

sent from a phone

> On 22. May 2019, at 01:43, Warin <61sundow...@gmail.com> wrote:
> 
> These take place in certain spots regularly around me. The popularity of the 
> spot might be related to the earnings.
> Are these jugglers accepting money for their 'performance'? If so it might be 
> a good idea to incorporate others who do a 'performance' that also accept 
> money.


I also frequently see jugglers at the traffic lights, but they are not frequent 
enough yet to map them ;-)

One guy is pretty good, he’s juggling 5 clubs on top of a ladder (the simple 
linear ladders, not the self-supporting)

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

Re: [Tagging] Feature Proposal - RFC - juggling spot

[Jmapb]

On 5/22/2019 4:30 AM, Marc Gemis wrote:

For me, a sport means competition, rankings, trophies. Is this the
case here? Otherwise, I think leisure is better.
A pitch a place specially designed for a certain sport. I think this
is not the case here. It's just an open space, which can also serve
other purposes.

I fear that a juggling spot is not something we should add to OSM,
We do not map places where you can skateboard, unless there is a
dedicated area to practice containing ramps, etc.


I tend to agree that a juggling "spot" would likely not be primarily
intended for juggling in any verifiable way, and so should not be mapped
on OSM.

But regarding your sport definition ("competition, rankings, trophies"):
there is wide tagging of non-competition sport features in OSM. Sport
values like skateboard, canoe, fishing, surfing may *occasionally* refer
to locations of competitive activity, but I'd wager the vast majority of
them are simply for leisure. Other common sport values like
scuba_diving, exercise, and yoga probably rarely if ever indicate a
competitive sport.

J


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

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Tobias Knerr]

On 08.05.19 01:30, Nick Bolten wrote:
> Would it be fair to say you're suggesting something along the lines of
> crossing:marking=*, where * can be yes, no, or a marking type? You make
> a good point about the simplicity of avoiding a subtag for markings.

Yes, this is pretty much what I'm suggesting. And I believe it would be
an useful tag no matter whether we make crossing mapping fully
orthogonal or just mostly orthogonal.

Taking a step back to explain my thoughts on splitting off signals...

The core of the issue seems to be that there are two conflicting
mindsets: Mapping "types" of crossings versus having a "construction
kit" of several tags which each describe one facet of the crossing.

If we want to have "types of crossings" at all, it would be highly
unexpected to ignore the presence of traffic signals for that purpose.
And the crossing=* key clearly seems to be intended for mapping the type
of the crossing. That meaning is suggested by the name of the key
itself, not just the current set of values, so I believe it's
counter-intuitive to turn it into just one of several equally important
orthogonal keys.

What else could we do with crossing=*? In theory, we could just get rid
of it entirely, but realistically, that's not going to fly, and I'm not
even sure if it would be desirable. People _do_ tend to mentally put
things to categories, and describing the most common crossings with just
one tag is certainly convenient.

So what I would probably do is mix the two approaches instead of going
for a conceptually pure implementation. Use
crossing=unmarked/marked/traffic_signals
for a basic classification of the crossing's type, and then add
orthogonal subtags like crossing:island=*, crossing:marking=* etc. as
needed. It lacks the elegance of full orthogonality, but covers all
practical use cases.

Tobias

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

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

[Rory McCann]

On 22/05/2019 14:31, Paul Allen wrote:

The problem with that is the same problem as allowing every language
on the planet to use their own abbreviations for month names.  Only
worse.


I'm not proposing that, I suggest we create a (short) list of accepted
calendar systems, and accepted abbreviations for each month in that
calendar. We don't have to expand it to all languages (you're right, it
would very impractical).

"Show in other languages" doesn't solve the problem of the months not
matching up.

Is this a real problem?  MARchesvan in the Judaic calendar is a 
collision with MARch, so we'd have to switch to 6-letter 
abbreviations.  The Islamic calendar has Rabi-Al-Awwal and 
Rabi-Al-Thani; Jumada-Al-Awwal and Jumada-Al-Thani; Zul-Qaadah and 
Zul-Hijjah, so that would need some though (are RAA, RAT, JAA, JAT, 
ZUQ ZUH acceptable?).


I'd leave it up to people familiar with the area to come up with good
abbreviations. I'm sure they already have recognizable abbreviations.

`opening_hours` is machine readable, but it's also (mostly) human
readable. If you put islamic/etc months in it, and a tool doesn't
support that, it can just display the raw tag text to the user who will
probably be able to read it and know what the opening hours are! By
putting data in `opening_hours` (not `opening_hours:islamic`) and using
local appropriate names, we retain that benefit. It degrades gracefully.


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

Re: [Tagging] Tagging a site with "Luxury Lodges"

[Mateusz Konieczny]

22 May 2019, 16:45 by tagging@openstreetmap.org:

>
> I hesitate to raise my simple question in such an expertforum, but I want to 
> tag correctly and cannot find the guidance I need in the Wiki.
>
>
Feel free to ask any questions how things should be tagged!

>
> How should I tag Willow Park in Salford Priors, near Evesham(UK)?>   > 
> https://www.openstreetmap.org/way/135928544 
> 
>
>
> Their website > http://willowparkluxurylodges.co.uk/ 
> >  talks of luxury lodges in the 
> countryside.>   > You cannot live there permanently, because the site is only 
> open for 11months of the year.>   > Instead, you buy a “lodge”on the site and 
> use it for holidays and weekends away (from the dirty, noisy city, where you 
> live, I assume).
>
>
Is it actually similar to buying a house? In that case it sounds to me like a 
residential area,
used as a secondary vacation home, not some hotel/caravan site and I would use 
landuse=residential.

Or is this "buying" a legal loophole and you may arrive, "buy" lodge, use it 
for two weeks and "sell" it,
with all this "buying" and "selling" being a legal fiction?

In that case it would be probably an expensive hotel.

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

[Tagging] Tagging a site with "Luxury Lodges"

[Peter Neale via Tagging]

I hesitate to raise my simple question in such an expertforum, but I want to 
tag correctly and cannot find the guidance I need in the Wiki.

How should I tag Willow Park in Salford Priors, near Evesham(UK)?  
https://www.openstreetmap.org/way/135928544

Their website http://willowparkluxurylodges.co.uk/talks of luxury lodges in the 
countryside. You cannot live there permanently, because the site is only open 
for 11months of the year.  Instead, you buy a “lodge”on the site and use it for 
holidays and weekends away (from the dirty, noisy city, where you live, I 
assume).

Individual Structures. 

The “lodges” are not “building=static_caravan”, as there isno pretence that 
they can be moved (See their website for pictures).  Theyare not really 
“building=cabin”, as they are not “…a small, roughly built houseusually with a 
wood exterior “.   I suppose they are “building=bungalow”,although (to me, at 
least) that would be more appropriate for a permanentdwelling that is single 
storey.   

The Entire Site.  

The site is currently tagged as “tourism=caravan_site”, but it is notfor 
tourists (“A person who is travelling or visiting a place for pleasure”. - 
https://en.oxforddictionaries.com/definition/tourist) and is not a caravan site 
(or RV Park, as the iD Editor calls it), becauseyou cannot arrive and park your 
Caravan, Tent, or RV there.

My inclination would be to tag is as some sort of leisuresite, but what sort???

It does not fit the Wiki definition of a “Leisure=Park” -  “Open, green area 
for recreation, usuallymunicipal”. 

Any advice, please?
 Peter 

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

Re: [Tagging] Runway area mapping?

[Paul Johnson]

On Mon, May 20, 2019, 21:57 Graeme Fitzpatrick 
wrote:

>
>
> On Tue, 21 May 2019 at 11:36, Joseph Eisenberg 
> wrote:
>
>> The current wiki page suggests using "aeroway:area=runway" to map the
>> outline of the runway, and mapping the "aeroway=runway" as a line
>> along the center of the runway.
>>
>> Does everyone agree that aeroway:area is the right way to map runway
>> areas, if this is considered necessary?
>>
>> And do we agree that runways should be mapped as linear ways, like
>> highways and railways, not only as an area?
>>
>
> I must admit that I only ever map the runway as a way, not an area.
>
> On the subject, I've just had a look at a few, & I see that there's now an
> option (in iD at least) for "Runway number", which then apparently appears
> as ref=.
>
> I've always put the runway number "14/32" in as the name=, & it's always
> seemed to work OK.
>

That should be ref=14;32, but otherwise, I agree.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Paul Johnson]

On Mon, May 20, 2019, 02:53 Martin Koppenhoefer 
wrote:

>
>
> Am Mo., 20. Mai 2019 um 07:53 Uhr schrieb Nick Bolten :
>
>> Hello everyone, this is a late addition to this thread (I'll start a new
>> one soon after I improve the proposal page), but I want to give an example
>> of a crossing that has lights but no markings that is traversed by
>> (guessing) thousands of people per day:
>> https://www.bing.com/maps?osid=0fa511ff-b1e5-4011-b16c-d96c0c4ce8a5=47.611664~-122.336542=19=251.4678=-22.174986=x=z.0=2=2=S00027.
>> Despite having a lot of interesting art, there is no way to distinguish the
>> crossing location from non-crossing locations via markings on the ground.
>>
>> This is topical, as crossing=traffic_signals is often claimed to imply
>> crossing=marked.
>>
>
>
> It is very common to see markings at traffic signal controlled crossings,
> but I would not see them as a requirement, and I do not think it is written
> anywhere that it should be. From my understanding, it seemed not
> interesting for most mappers to distinguish traffic light controlled
> markings from unmarked ones, and you will likely have a hard time to
> convince them (as this thread shows) to retag all crossings just because
> there may be exceptions or situations where it may be relevant.
>

Can confirm, marked crosswalks are pretty rare in Oklahoma even at traffic
lights.  Only some school crossings and high pedestrian traffic corners
have them marked, typically.  Otherwise marked crosswalks tend to be for
crosswalks in unusual locations (like midblock).

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

Re: [Tagging] Feature Proposal - RFC - changing table

[Valor Naram]

Yes, right. Sry for this. I learnt that "floor" means "Flur" in german language. Seems to be incorrect. Original Message Subject: Re: [Tagging] Feature Proposal - RFC - changing tableFrom: Michael Brandtner via Tagging To: tagging@openstreetmap.orgCC: Michael Brandtner 
I think that this is a language issue and the hallway (German "Flur") is meant, not the floor.





Am Dienstag, 21. Mai 2019, 03:11:32 MESZ hat marc marc  Folgendes geschrieben:



Hello, > https://wiki.openstreetmap.org/wiki/Proposed_features/changing_tablequestions / minor suggestions :in changing_table:location=room what's the usecase of :"or the floor to the toilets" ? maybe just drop it.if someone wants to put their child on the floor, I don't see howwe could describe that this floor is adapted but not this other onethe first sentence of the tagging paragraph is about the rational (why some other existing tag doesn't fit the need),drop or move it to the rational paragraphRegards,Marc___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Feature Proposal - RFC - changing table

[Michael Brandtner via Tagging]

 I think that this is a language issue and the hallway (German "Flur") is 
meant, not the floor.

Am Dienstag, 21. Mai 2019, 03:11:32 MESZ hat marc marc 
 Folgendes geschrieben:  
 
 Hello,

 > https://wiki.openstreetmap.org/wiki/Proposed_features/changing_table

questions / minor suggestions :

in changing_table:location=room what's the usecase of :
"or the floor to the toilets" ? maybe just drop it.
if someone wants to put their child on the floor, I don't see how
we could describe that this floor is adapted but not this other one

the first sentence of the tagging paragraph is about the rational (why 
some other existing tag doesn't fit the need),
drop or move it to the rational paragraph

Regards,
Marc
___
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] Navaid relation?

[marc marc]

Le 22.05.19 à 12:06, Florian Lohoff a écrit :
>> you mean https://www.openstreetmap.org/way/273023376 ?
>> it's a good example of missing datas.
>> no entrance, no way between the entrance and the public network.
>> I feel that the relation type=navaids should be called type=missingway
> 
> Again a footway between the house and a road will NOT help for
> car navigation because for cars a footway is NOT a routable
> part of the graph.

again multimodal app DO it (for e.g. switch footway with 
access=destination in a BRouter car profile, you may also add a weight
despite i didn't known how to add a big weight for missing way)

when datas are available, an application can choose to prefer the most 
complete routing to reatch a entrance even if a part is done by foot 
compared to a closer routing by car but for witch the routing till the 
destination is unknown and can therefore cross a barrier or anything 
that invalidates the routing.
it's a matter of weight between the footway and the "no-way" and/or a 
test to avoid a routing between the last routed-by-car node and the 
destination through a barrier

so first :
- add missing datas that have already an osm tag
- have an app that use those datas
MAYBE AFTER that some additional datas are needed,
but without using currently usable infos, our exemple
get the reply "use eisting datas"
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Navaid relation?

[Colin Smale]

Navigation software needs to move on. Instead of mapping a destination
POI to a single point in every case, it needs to handle a list of
points. Each point may have filters or qualifiers, such as opening hours
or mode of transport; this can lead to some of the points being
disqualified. The routing needs to calculate a route to each remaining
point and choose the best one using the routing criteria (shortest,
fastest etc). The multiple route calculations don't always need to
restart from the departure point - I'm sure a heuristic to limit the
recalculation to the last X km would be fine in most cases. 

Then in the OSM data we need a way of indicating that multiple points
are initially equivalent, serving the same POI. For example, multiple
car parks serving the same public park. This can be purely geometric, by
virtue of the car parks being enclosed by the parks outer perimeter, or
by some kind of association relation. Reducing a car park polygon to a
candidate point for the above multiple-routing case can be based on a
node with entrance=* or the intersection with an accessible highway.
Where a car park has multiple entrances, add them all into the candidate
point list as above. 

Regarding the use of footways for vehicle navigation, there are plenty
of multimodal public transport planners out there, which know about
trains, buses, walking etc. They work much more from point to point, not
limited to just the vehicle segment of the journey. A car
router/navigator can do the same, can't it? It will of course rely on
the data it is given 

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

Re: [Tagging] Navaid relation?

[Mateusz Konieczny]

22 May 2019, 13:03 by f...@zz.de:

> On Wed, May 22, 2019 at 12:55:44PM +0200, Mateusz Konieczny wrote:
>
>> > - Baumstraße 43a, Gütersloh, Germany
>> >  It does not have a connection to Baumstraße but to
>> >  Hermann-Vogelsang-Straße.
>> >
>> >  It still will be routed through Baumstraße and the driveway to
>> >  Baumstraße 45a
>> >
>> >  IMHO unfixable without bending geometry 
>> >
>> https://www.openstreetmap.org/way/273023376 
>>  has no mapped entrance, 
>> footway access, driveway. Fences are also unmapped.
>>
>
> Footway -> not for car 
> fences -> not in graph for navigation - not connected to graph-> purely
> cosmetic object.
>
It is possible for routers to use fence/footway data to select good dropoff 
location.

I am not claiming that there are routers doing this now, but it is possible to 
do
and better solution that manual routing with relations.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Navaid relation?

[Mateusz Konieczny]

22 May 2019, 13:00 by f...@zz.de:

>
> Hi
>
> On Wed, May 22, 2019 at 12:42:45PM +0200, Mateusz Konieczny wrote:
>
>> 22 May 2019, 09:53 by f...@zz.de:
>> > Hi Marc,
>> > On Tue, May 21, 2019 at 10:38:23PM +, marc marc wrote:
>> >> > What is the expectation to get navigated to when selecting a park?
>> >> there is no such thing as "a single point that makes everyone agree"
>> > Yes there is - there has to be an explicit location you will ne navigated
>> > to for a certain feature. 
>> >
>> This is blatantly untrue. Depending on location you will prefer to be routed
>> to different entrances and it is not considering different modes of 
>> transport.
>>
>
> How can i select the entrance on OSRM/openstreetmap website, MAPS.ME,
> OsmAND the entrance? You cant. 
>
Why would you want to manually select entrance?

See for example router selecting appropriate entrance based on location:

http://brouter.de/brouter-web/#map=16/50.0645/19.9179/standard=19.916883,50.065609;19.917483,50.062799=shortest
 


http://brouter.de/brouter-web/#map=16/50.0645/19.9179/standard=19.918041,50.059245;19.917483,50.062799=shortest

> And when navigating by car to
> a mall i dont want the entrance - i want the Car park. Can i select
> that from a drop down when selecting a Mall to navigate to?
>
It should be automatically preferred for car routing. I admit that I have no 
router to
recommend, as I am not using car. But have you tried requesting improvements
for your navigation (assuming that it has a a public bug tracker and it was not
requested already)?

> Mapping OSM Objects to navigational locations is implicit right now and
> depends on the algorithm used to find the nearest location on the
> routable network for the specified mode of transportation. So i bet
> i can generate a situation where OSMAnd, OSRM and MAPS.ME will bring
> you to different spots more than 5km apart. 
>
What is wrong with that?

> And dont troll me with "add a footway" - A footway is not in the
> routable graph for cars and will not even be in the database when
> looking for the nearest point.
>
Router can use footway data to select good dropoff point. 
And other info like parkings.

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

Re: [Tagging] Navaid relation?

[Florian Lohoff]

On Wed, May 22, 2019 at 01:01:20PM +0200, Mateusz Konieczny wrote:
> 
> 22 May 2019, 12:49 by f...@zz.de:
> 
> > On Wed, May 22, 2019 at 12:37:21PM +0200, Mateusz Konieczny wrote:
> >
> >> > Again a footway between the house and a road will NOT help for
> >> > car navigation because for cars a footway is NOT a routable 
> >> > part of the graph.
> >> >
> >> Car navigation may use footway data to select best dropoff point.
> >>
> >> In exactly the same way as you proposed with navaid relation,
> >> but without adding subjective data.
> >>
> >
> > Look at my school example - would still be broken. Yes - there is a
> > footway - but not the original parking lot for the school.
> >
> > Different street. ~1km detour. No parking at the selected spot - Private
> > property.
> >
> > You are trying to fix an algorithm with new assumptions which break in
> > other aspects. You need to have a way to EXPLICITLY define a location
> > where to navigate to. 
> >
> I noticed no link to that case, but here routers should direct car to mapped
> parking within school area (it is a public parking, right?).

Search for it - When i add a link i add a specific location - I did this
intentionally - Because with the search you map object -> specific
location and then you can query OSRM again for routing.

It is the official parking lot for the school. Its vis a vis to the 
entrance.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Navaid relation?

[Florian Lohoff]

On Wed, May 22, 2019 at 12:55:44PM +0200, Mateusz Konieczny wrote:
> > - Baumstraße 43a, Gütersloh, Germany
> >  It does not have a connection to Baumstraße but to
> >  Hermann-Vogelsang-Straße.
> >
> >  It still will be routed through Baumstraße and the driveway to
> >  Baumstraße 45a
> >
> >  IMHO unfixable without bending geometry 
> >
> https://www.openstreetmap.org/way/273023376 
>  has no mapped entrance, 
> footway access, driveway. Fences are also unmapped.

Footway -> not for car 
fences -> not in graph for navigation - not connected to graph-> purely
cosmetic object.

43a has no footway/driveway. The carport is directly at the side of the
road.

> I am not sure whatever we have smart routers, but here even human would fail
> due to lack of data.
> 
> I added driveway based on aerial image but it is unlikely to be enough.

Where is it ? 43a does not have a driveway.

> > - Dalbker Straße 40a, Oerlinghausen, Germany 
> >  Dalbker Straße 44a, Oerlinghausen, Germany 
> >
> Fences/hedges/whatever barrier is there is missing though
> really smart router (that is using footway at start and the end)
> would work correctly here.
> 
> Have you checked whatever this improvement is suggested for routers with 
> public
> bug trackers?

Okay - first you tell me - its solvable - then you tell me data is
missing, now you tell me the software is broken.

And there is a footway - its directly in front of the door. Still - you
will get routed to a differen street. The footway is NOT in the graph
for cars. 

All objects you put into this argument do not have any influence on any
routing app/software mentioned in this thread before.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Navaid relation?

[Mateusz Konieczny]

22 May 2019, 12:49 by f...@zz.de:

> On Wed, May 22, 2019 at 12:37:21PM +0200, Mateusz Konieczny wrote:
>
>> > Again a footway between the house and a road will NOT help for
>> > car navigation because for cars a footway is NOT a routable 
>> > part of the graph.
>> >
>> Car navigation may use footway data to select best dropoff point.
>>
>> In exactly the same way as you proposed with navaid relation,
>> but without adding subjective data.
>>
>
> Look at my school example - would still be broken. Yes - there is a
> footway - but not the original parking lot for the school.
>
> Different street. ~1km detour. No parking at the selected spot - Private
> property.
>
> You are trying to fix an algorithm with new assumptions which break in
> other aspects. You need to have a way to EXPLICITLY define a location
> where to navigate to. 
>
I noticed no link to that case, but here routers should direct car to mapped
parking within school area (it is a public parking, right?).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Navaid relation?

[Florian Lohoff]

Hi

On Wed, May 22, 2019 at 12:42:45PM +0200, Mateusz Konieczny wrote:
> 22 May 2019, 09:53 by f...@zz.de:
> > Hi Marc,
> > On Tue, May 21, 2019 at 10:38:23PM +, marc marc wrote:
> >> > What is the expectation to get navigated to when selecting a park?
> >> there is no such thing as "a single point that makes everyone agree"
> > Yes there is - there has to be an explicit location you will ne navigated
> > to for a certain feature. 
> >
> This is blatantly untrue. Depending on location you will prefer to be routed
> to different entrances and it is not considering different modes of transport.

How can i select the entrance on OSRM/openstreetmap website, MAPS.ME,
OsmAND the entrance? You cant. 

And where is an entrance to a Golf Course? And when navigating by car to
a mall i dont want the entrance - i want the Car park. Can i select
that from a drop down when selecting a Mall to navigate to?

Mapping OSM Objects to navigational locations is implicit right now and
depends on the algorithm used to find the nearest location on the
routable network for the specified mode of transportation. So i bet
i can generate a situation where OSMAnd, OSRM and MAPS.ME will bring
you to different spots more than 5km apart. Its just a matter of
constructing the right geometries with the tags one or the other
navigational preprocessing takes into account. You cant specify
the right location explicitly - so you need to rely on implicit geometry
processing by algorithms. And then you still have 2-3% of broken
destinations.

> > Nope - there isnt enough information. Its all just implicit and works
> > for 95% of the cases. It breaks horrible in others and we fake
> > geometries to fix it, blame the application, invent tags to guide the
> > nav/routing which only fit half of the object and only half of the
> > apps support. In all cases the user is in trouble.
> >
> Please give a specific example.

See my School example. Its a pretty nice fuck up. You get "near" the
School but in a oneway maze 1km away from the parking lot. And yes -
there is a footway. Everything is mapped as it is. Still - breaks.

https://lists.openstreetmap.org/pipermail/tagging/2019-May/045416.html
https://lists.openstreetmap.org/pipermail/tagging/2019-May/045423.html

And dont troll me with "add a footway" - A footway is not in the
routable graph for cars and will not even be in the database when
looking for the nearest point.

> If navigation is simply doing nearest road point on matching then it requires 
> change to both
> - properly use footway data
> - use your proposed relation

footway != car

And it wont solve the issue. See the school example. There is a footway
and it will prefer the location it does not most likely. Still broken.

nearest road point will only be on roads for THAT mode of
transportation.

> I see no reason for preferring second solution.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Navaid relation?

[Mateusz Konieczny]

22 May 2019, 09:43 by f...@zz.de:

>
> Hola Mateusz,
>
> On Wed, May 22, 2019 at 12:26:01AM +0200, Mateusz Konieczny wrote:
>
>> 21 May 2019, 23:46 by f...@zz.de:
>>
>> > - Houses which are routeable by road a but are near road b or vice
>> >  versa.
>> >
>> > Adding more roads aka service/driveway does not necessary make it more
>> > deterministic.
>> >
>> Can you give example of residential building with fully mapped roads, 
>> footways
>> and obstacles where well written router will fail?
>>
>
> - Baumstraße 43a, Gütersloh, Germany
>  It does not have a connection to Baumstraße but to
>  Hermann-Vogelsang-Straße.
>
>  It still will be routed through Baumstraße and the driveway to
>  Baumstraße 45a
>
>  IMHO unfixable without bending geometry 
>
https://www.openstreetmap.org/way/273023376 
 has no mapped entrance, 
footway access, driveway. Fences are also unmapped.

I am not sure whatever we have smart routers, but here even human would fail
due to lack of data.

I added driveway based on aerial image but it is unlikely to be enough.

>
> - Dalbker Straße 40a, Oerlinghausen, Germany 
>  Dalbker Straße 44a, Oerlinghausen, Germany 
>
Fences/hedges/whatever barrier is there is missing though
really smart router (that is using footway at start and the end)
would work correctly here.

Have you checked whatever this improvement is suggested for routers with public
bug trackers?

> moving it further to
>  Dalkbker Straße within the outline of the Building.
>
within the outline? In case it is acceptable

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

Re: [Tagging] Navaid relation?

[Florian Lohoff]

On Wed, May 22, 2019 at 12:37:21PM +0200, Mateusz Konieczny wrote:
> > Again a footway between the house and a road will NOT help for
> > car navigation because for cars a footway is NOT a routable 
> > part of the graph.
> >
> Car navigation may use footway data to select best dropoff point.
> 
> In exactly the same way as you proposed with navaid relation,
> but without adding subjective data.

Look at my school example - would still be broken. Yes - there is a
footway - but not the original parking lot for the school.

Different street. ~1km detour. No parking at the selected spot - Private
property.

You are trying to fix an algorithm with new assumptions which break in
other aspects. You need to have a way to EXPLICITLY define a location
where to navigate to. 

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Navaid relation?

[Mateusz Konieczny]

22 May 2019, 09:53 by f...@zz.de:

>
> Hi Marc,
>
> On Tue, May 21, 2019 at 10:38:23PM +, marc marc wrote:
>
>> > What is the expectation to get navigated to when selecting a park?
>>
>> there is no such thing as "a single point that makes everyone agree"
>>
>
> Yes there is - there has to be an explicit location you will ne navigated
> to for a certain feature. 
>
This is blatantly untrue. Depending on location you will prefer to be routed
to different entrances and it is not considering different modes of transport.

>> > Doesnt work - You are navigating by car but you only have a footway up
>> > to hour house - Still the house is near road b - thus you get navigated
>> > to the wrong street.
>>
>> that's a bug/a feature needed in the routing, all info exist in osm
>> to find the path to reatch to the house, instead of leaving you at
>> a closer location but whose routing to the house is unknown
>>
>
> Nope - there isnt enough information. Its all just implicit and works
> for 95% of the cases. It breaks horrible in others and we fake
> geometries to fix it, blame the application, invent tags to guide the
> nav/routing which only fit half of the object and only half of the
> apps support. In all cases the user is in trouble.
>
Please give a specific example.

> No - i expect to select a feature and when there are multiple entrances
> i expect the Nav to ask me. Currently it doesnt - no application does.
> They simply guide me to some arbitrarily choosen point calculated
> from some geomtry which fits some nearest point matching algorithm. And
> there is NO way to fix this.
>
If navigation is simply doing nearest road point on matching then it requires 
change to both
- properly use footway data
- use your proposed relation

I see no reason for preferring second solution.


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

Re: [Tagging] Navaid relation?

[Mateusz Konieczny]

22 May 2019, 12:06 by f...@zz.de:

> On Wed, May 22, 2019 at 09:13:14AM +, marc marc wrote:
>
>> Le 22.05.19 à 09:43, Florian Lohoff a écrit :
>> >> Can you give example of residential building with fully mapped roads, 
>> >> footways and obstacles where well written router will fail?
>> > 
>> > - Baumstraße 43a, Gütersloh, Germany
>>
>> you mean https://www.openstreetmap.org/way/273023376 ?
>> it's a good example of missing datas.
>> no entrance, no way between the entrance and the public network.
>> please, there should be an example of a target where the current schema 
>> are not enough, and not an example where the lack of data produce
>> a bad routing
>>
>> right now I feel that the relation type=navaids should be called 
>> type=missingway
>>
>
> Again a footway between the house and a road will NOT help for
> car navigation because for cars a footway is NOT a routable 
> part of the graph.
>
Car navigation may use footway data to select best dropoff point.

In exactly the same way as you proposed with navaid relation,
but without adding subjective data.

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

Re: [Tagging] Feature Proposal - RFC - juggling spot

[Tom Pfeifer]

On 22.05.2019 00:09, marc marc wrote:

I you think that juggling is a sport, sport tag exist,
just add sport=juggling

but we miss a main tag for sport that does not take place on a delimited
sports field, the same issue exist with outdoor sport=scuba_diving


maybe leisure=location or leisure=sport[s]_location ?

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

Re: [Tagging] Navaid relation?

[Florian Lohoff]

On Wed, May 22, 2019 at 09:13:14AM +, marc marc wrote:
> Le 22.05.19 à 09:43, Florian Lohoff a écrit :
> >> Can you give example of residential building with fully mapped roads, 
> >> footways and obstacles where well written router will fail?
> > 
> > - Baumstraße 43a, Gütersloh, Germany
> 
> you mean https://www.openstreetmap.org/way/273023376 ?
> it's a good example of missing datas.
> no entrance, no way between the entrance and the public network.
> please, there should be an example of a target where the current schema 
> are not enough, and not an example where the lack of data produce
> a bad routing
> 
> right now I feel that the relation type=navaids should be called 
> type=missingway

Again a footway between the house and a road will NOT help for
car navigation because for cars a footway is NOT a routable 
part of the graph.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Navaid relation?

[marc marc]

Le 22.05.19 à 09:43, Florian Lohoff a écrit :
>> Can you give example of residential building with fully mapped roads, 
>> footways and obstacles where well written router will fail?
> 
> - Baumstraße 43a, Gütersloh, Germany

you mean https://www.openstreetmap.org/way/273023376 ?
it's a good example of missing datas.
no entrance, no way between the entrance and the public network.
please, there should be an example of a target where the current schema 
are not enough, and not an example where the lack of data produce
a bad routing

right now I feel that the relation type=navaids should be called 
type=missingway
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Navaid relation?

[marc marc]

Le 22.05.19 à 10:36, Florian Lohoff a écrit :
> type navaid
> source  (Multiple ones sharing the same transport 
> destination)
> car
> bicyle 
> foot   

this info, for well mapped objet, already exist
polygon   have several nodes
with entrance=yes and car/bicyle/foot=designated
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Navaid relation?

[Florian Lohoff]

Hi Peter,

On Wed, May 22, 2019 at 10:15:57AM +0200, Peter Elderson wrote:
> >  Id imaging a relation which says
> > object A -> car -> Node B (on routable graph)
> > So whenever i tell my nav software to bring me to object A the node
> > selected on the routable graph as a destination will be Node B.
> 
> One relation per mode of transport then? So a complex obejct a could have
> many navaid relations? Or one relation containing all nodes, with roles for
> transport mode?

type navaid
name Foobar (Optional if object does not carry a name or you map
 multiple different location)
source  (Multiple ones sharing the same transport destination)
car
bicyle 
foot   

Just as the rough first version. You want to keep this to a minimum for
cases where an algorithm cant choose the right solution or is making
wrong decisions based on correct geometries.

A mall with parking south and north would get 2 navaid relations

name "Mall foo - North"
name "Mall foo - South"

With their parking lot entries as the nodes to go to by car
and their entrance for foot. Currently you might be lucky
that your Nav Software does a full text search and somebody
named the parking lots with the complete name although
they should only carry a ref=North/South.

So a navigation preprocessor would not try to find a node on the
routable network by algorithm but by hinting in case it finds
this relation.

It currently works by accident and because people tweak
the data to get their result. Either geometries, additional tags
or additional name tags on unrelated objects. 

People start mapping for the router/nav software. A relation like this
could help solve the need of hinting the software without abusing
other tags, tag move, geometry tweaking.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Feature Proposal - RFC - juggling spot

[Marc Gemis]

For me, a sport means competition, rankings, trophies. Is this the
case here? Otherwise, I think leisure is better.
A pitch a place specially designed for a certain sport. I think this
is not the case here. It's just an open space, which can also serve
other purposes.

I fear that a juggling spot is not something we should add to OSM,
We do not map places where you can skateboard, unless there is a
dedicated area to practice containing ramps, etc.

As a solution, you create a umap with spots for juggling.

regards

m.

On Wed, May 22, 2019 at 9:28 AM Pablo  wrote:
>
> Thx for your answers :).
>
> I m speaking of juggling as a sport and not as entertainment. These meetings 
> are not organised to earn money or to make shows, but to practice and meet 
> each other.
>
> I don't know any spaces primarily used for juggling, bukers, scuba diving, 
> slack line, or other sport that don't need peculiar infrastructures. (Even 
> ski station are not primarily used for ski in summer). So why not use the tag 
> leisure = pitch sport=juggling?  And if needed adding another sport=whatever.
>
> Verifiability : it s only verifiable in the dates where people meet (in 
> winter theses places are commonly not used). As, you can't verify the 
> proprieties of a shop went it's close. Sometime the address can be find on 
> the website of the juggling association or on Facebook groups, sometimes you 
> have to find the people who know where and when theses meeting occurs. In any 
> case it can be verified but not anytime.
>
> However, this ephemeral  spaces exist and are used. So I think it could be 
> usefull to create a maintag "for sport that does not take place on a delimited
> sport field". This wild resolve the problem of the format leisure = pitch 
> sport = juggling. Don t you think ?Le 22 mai 2019 00:05, Jmapb 
>  a écrit :
> >
> > On 5/21/2019 3:34 PM, Pablo wrote
> > > A new feature proposal which could be very useful for the juggling 
> > > community. Usually, jugglers meet in specific spaces in cities (usually 
> > > open spaces like parcs). There is often a day of the week which is choose 
> > > to meet in priority. It s like a informal sport center. I thinks it s the 
> > > same thing for slack lines and acrobatics but I m not sure. Osm could 
> > > help find theses spots which is very usefull when you travel. If this tag 
> > > is accepted, I will inform the juggling community so they can add their 
> > > spots.
> > > You can find it here :
> > > https://wiki.openstreetmap.org/wiki/Proposed_features/juggling_spot
> >
> > juggling=spot is not a great tag, since it doesn't follow the existing
> > tagging conventions. Better would be sport=juggling -- but the sport=*
> > tag has to be added to some other physical feature; it's not a valid tag
> > all by itself.
> >
> > If there's a signed or otherwise documented and verifiable place that's
> > *primarily* designed/used for juggling, it could be tagged leisure=pitch
> > + sport=juggling.
> >
> > If this use not verifiable by other mappers, the juggling tag will
> > probably be deleted.
> >
> > J
> >
> > ___
> > 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] Navaid relation?

[Florian Lohoff]

On Wed, May 22, 2019 at 09:43:31AM +0200, Florian Lohoff wrote:
> > Can you give example of residential building with fully mapped roads, 
> > footways
> > and obstacles where well written router will fail?
> 
> - Baumstraße 43a, Gütersloh, Germany
>   It does not have a connection to Baumstraße but to
>   Hermann-Vogelsang-Straße.
> 
>   It still will be routed through Baumstraße and the driveway to
>   Baumstraße 45a
> 
>   IMHO unfixable without bending geometry 
> 
> - Dalbker Straße 40a, Oerlinghausen, Germany 
>   Dalbker Straße 44a, Oerlinghausen, Germany 
>   Both fixed by moving the Address to a node, moving it further to
>   Dalkbker Straße within the outline of the Building.
> 
>   Otherwise you'd be routed to Buchweizenweg without access to
>   the Building. This is what multiple of my collegues complained
> about.
> 
>   Here i bend geometry until it halfway worked.
> 
> Just 2 examples for the last 10 days or so. And footways wont help
> you in a car profile. You could bring a footway directly connecting
> the entrance to the Street.

And most likely - Try and schools in your area. If its correctly
mapped with the school ground as an amenity=school and buildings
etc.

Try to reach it by car:

Elly-Heuss-Knapp Realschule, Gütersloh

You'll end on the wrong street without parking and a gate although
the school has a parking lot. And you even end up in a oneway hell.

Whenever you try to reach "large" osm objects on the routable network
you are in deep trouble. camp sites, airports, golf courses, schools.
People move the attributes from the polygons to nodes to make it
explicit where to navigate. With polygons its up to the algorithm
to guess the right point.

And i had tons of stuff like this the last decade. 2 Years ago
i ended up on a road at a river (by bike) the campsite on the opposite
side of the river. 5km to next bridge to cross the river because the
road 20m on the other river side was the nearest point on the routable
network. Roads on the campsite were access=private. 

I ended here:
https://www.openstreetmap.org/?mlat=53.92106=12.10538#map=17/53.92106/12.10538

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Navaid relation?

[Peter Elderson]

>  Id imaging a relation which says
> object A -> car -> Node B (on routable graph)
> So whenever i tell my nav software to bring me to object A the node
> selected on the routable graph as a destination will be Node B.

One relation per mode of transport then? So a complex obejct a could have
many navaid relations? Or one relation containing all nodes, with roles for
transport mode?
Vr gr Peter Elderson


Op wo 22 mei 2019 om 10:02 schreef Florian Lohoff :

> On Wed, May 22, 2019 at 08:31:03AM +1000, Graeme Fitzpatrick wrote:
> > On Wed, 22 May 2019 at 07:47, Florian Lohoff  wrote:
> > > - Houses which are routeable by road a but are near road b or vice
> > >   versa.
> >
> > That could be a "problem" due to GPS (?) system being so accurate?
>
> And map data beeing very accurate. With commercial data sets you'll map
> addresses to street segments. Done.
>
> We aim much higher. We want exact locations of buildings and we expect
> some clever algorithms to match these addresses to roads. Works for
> 90% of the cases. And fails in others.
>
> And then we aim even higher. We want all the corner cases to work.
> Issues as the above - Address on road A - Reachable only via road B but
> near road A. Without hinting there is no way an algorithm will be able
> to determine this.
>
> > For instance, where I am sitting now at the back of my house, various
> GPS /
> > location / navigation systems tell me that I am actually at the address
> > behind us, of That Road, rather than My Street, because I'm about 1m
> closer
> > to that street!
> >
> > If I turn OSMand on & ask it to take me from my present location to my
> > Home, it will tell me to walk or drive around the block!
>
> Its not an GPS issue - Navigation works different - You tell where you
> want to go and it selects a precise and explicit point on the routing
> graph where to take you to. And it'll follow on the graph to that
> location. The mapping of an address to a location on the routeable
> graph is the Problem - not the routing/gps. This is why i called
> it "navaid" not "routingaid".
>
> Id imaging a relation which says
>
> object A -> car -> Node B (on routable graph)
>
> So whenever i tell my nav software to bring me to object A the node
> selected on the routable graph as a destination will be Node B.
>
> Flo
> --
> Florian Lohoff f...@zz.de
> UTF-8 Test: The  ran after a , but the  ran away
> ___
> 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 - Voting - camp_site=camp_pitch

[Martin Koppenhoefer]

Am Mi., 22. Mai 2019 um 06:12 Uhr schrieb Tod Fitch :

> it's an argument that makes sense.
> perhaps in this case, should we start by proposing to depreciate
> camp_site=pitch and camp_site=camp_pitch since these are the 2 most
> problematic in the logic of tag linking
>
>

+1


> >
> With respect to tourism=camp_pitch, it seems to have limited use (227
> instances). I see no wiki on it at all, not even a proposal. So I don’t
> know if the taggers intended it to be for a place within a campsite or not.
> It has the unfortunate characteristic that it conflicts with
> tourism=camp_site so you can’t tag a site with only one place for
> tent/caravan with both camp_site (so it can be found at a top level by
> someone looking for camp sites) and camp_pitch (so you can potentially list
> the detailed characteristics (table, fire ring, etc.).
>


this could be seen as an advantage: it would by default not show those
places with just one pitch and likely no services, to people doing a simple
query for camp sites on a generic service, while those people which are
potential users of those basic backcountry pitches will likely use a
specific map optimized for hiking.

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

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

[Rory McCann]

On 17/05/2019 21:13, Paul Allen wrote:
I think that you would have to come up with something like 
opening_house:islamic or something like that to segregate the two

systems.

There are some downsides to using a new `opening_hours:islamic` key:

 * What happens if there's an `opening_hours=*` and
`opening_hours:islamic=*` tag on the same object? And what if they are
correct?
 * Many OSM data consumers look at the `opening_hours` tag, and they
aren't aware of this new key.

I don't know much about the islamic calendar. Could you give some 
examples of what data you'd like to enter? Most "opening hours" don't 
need to include years, so is that a problem? You could just use the 
islamic calendar month names if needed.


So I suggest just adding the opening hours that would make sense for a 
local into the `opening_hours` tag, and follow the spirit of the 
opening_hours syntax.


--
R/A/McC


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

Re: [Tagging] Feature Proposal - Voting - camp_site=camp_pitch

[Martin Koppenhoefer]

sent from a phone

> On 20. May 2019, at 18:19, Markus  wrote:
> 
> I prefer the camp_site:part=camp_pitch because the :part suffix is
> already in use in building:part=* and could become a standard suffix
> for parts of other objects, such as named parts of forests or lakes,
> numbered grave fields of cemeteries or thematic parts of botanical
> gardens or parks (e.g. medicinal herbs, asian plants, succulents).


While it somehow works for buildings where the sum of all building:parts make 
up the whole building, and the parts may „exist“ in the real world as concept 
(have a name, be functionally defined), the same concept works less for camping 
sites, because you won’t generally be able to divide it into parts with the sum 
of them making the whole campsite (many components are already tagged 
differently, like leisure pitches, beaches, paths, shops, bathrooms, ...). And 
the pitch as part of a campsite is much less a common concept in the real 
world. There is already the spatial and semantic relation of the pitches inside 
the campsite so that it is not useful to restate this in the key. 
camp_site:part=yes would not make a lot of sense, would it? We also have 
examples where the parts are classified as their own class aside the 
“container”, e.g. place=city and suburb, quarter, neighborhood 
or amenity=bank, atm
“Things inside things” is one of the core concepts which is inherent to 
OpenStreetMap and making a map in general, there are no tags needed for mapping 
it.

Forest names (and geographic regions in general) are another issue that we have 
not solved thoroughly, because there are actually different types of “forests”: 
there are many small parts, often with names in densely populated places, which 
together form bigger areas with their own name (often/generally), which may 
form bigger parts again with a distinct name, and so on. Some names refer only 
to a patch of land with trees growing on them (and these can be represented 
well in osm), but the bigger they become, the more areas will be included where 
there aren’t actually trees growing. Those bigger entities aren’t “forests” in 
the osm sense, they are geographic regions with typically soft boundaries, for 
which we haven’t established any concept or convention yet. Adding a “:part” 
component does not solve these cases, it would again just be repeating with 
words what is already in the spatial structure.

On top of these points, the key
camp_site:part=camp_pitch
is inconveniently long and ugly, featuring a colon and two underscores in the 
same tag ;-)
If for some reason we don’t want to use the tourism key for these, the tag 
could still be much more simple, e.g.
camping=pitch

Cheers, Martin 


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

Re: [Tagging] Navaid relation?

[Florian Lohoff]

On Wed, May 22, 2019 at 08:31:03AM +1000, Graeme Fitzpatrick wrote:
> On Wed, 22 May 2019 at 07:47, Florian Lohoff  wrote:
> > - Houses which are routeable by road a but are near road b or vice
> >   versa.
> 
> That could be a "problem" due to GPS (?) system being so accurate?

And map data beeing very accurate. With commercial data sets you'll map
addresses to street segments. Done. 

We aim much higher. We want exact locations of buildings and we expect
some clever algorithms to match these addresses to roads. Works for 
90% of the cases. And fails in others.

And then we aim even higher. We want all the corner cases to work.
Issues as the above - Address on road A - Reachable only via road B but
near road A. Without hinting there is no way an algorithm will be able
to determine this.

> For instance, where I am sitting now at the back of my house, various GPS /
> location / navigation systems tell me that I am actually at the address
> behind us, of That Road, rather than My Street, because I'm about 1m closer
> to that street!
> 
> If I turn OSMand on & ask it to take me from my present location to my
> Home, it will tell me to walk or drive around the block!

Its not an GPS issue - Navigation works different - You tell where you
want to go and it selects a precise and explicit point on the routing
graph where to take you to. And it'll follow on the graph to that
location. The mapping of an address to a location on the routeable
graph is the Problem - not the routing/gps. This is why i called
it "navaid" not "routingaid".

Id imaging a relation which says

object A -> car -> Node B (on routable graph)

So whenever i tell my nav software to bring me to object A the node
selected on the routable graph as a destination will be Node B.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Navaid relation?

[Florian Lohoff]

Hi Marc,

On Tue, May 21, 2019 at 10:38:23PM +, marc marc wrote:
> > What is the expectation to get navigated to when selecting a park?
> 
> there is no such thing as "a single point that makes everyone agree"

Yes there is - there has to be an explicit location you will ne navigated
to for a certain feature. 

It might be that there are multiple - then you might want to choose.
Currently you'll be guided to a random location which fits whatever
nearest point algorithm your router/navigation uses. Non deterministic
from a users perspective.

> take the case of a square park fenced by a fence, surrounded by 4 
> streets each with a pedestrian entrance to the park.
> those arriving from the north will probably want to stop at the street 
> to the north, while those arriving from the south will probably want to 
> stop at the street at the south entrance.

Tell me ONE application that does this. None. All of them map a feature
you select (Address, POI, whatever) - map it to a single precise point
and bring you there.

> > Doesnt work - You are navigating by car but you only have a footway up
> > to hour house - Still the house is near road b - thus you get navigated
> > to the wrong street.
> 
> that's a bug/a feature needed in the routing, all info exist in osm
> to find the path to reatch to the house, instead of leaving you at
> a closer location but whose routing to the house is unknown

Nope - there isnt enough information. Its all just implicit and works
for 95% of the cases. It breaks horrible in others and we fake
geometries to fix it, blame the application, invent tags to guide the
nav/routing which only fit half of the object and only half of the
apps support. In all cases the user is in trouble.

> > Detaching addresses from house geometries putting it near the road 
> > i expect people to be navigated to.
> 
> so UGLY ! You decide, for the example of the park, that everyone
> must use YOUR favorite entrance.

No - i expect to select a feature and when there are multiple entrances
i expect the Nav to ask me. Currently it doesnt - no application does.
They simply guide me to some arbitrarily choosen point calculated
from some geomtry which fits some nearest point matching algorithm. And
there is NO way to fix this.

> it is tagging for your-routing, instead of allowing routing to have 
> personalized options (shortest route, least walking, close to a parking, 
> disabled accessible up to the poi)

No - as i said - its about hinting. We have a low percentage of
nav targets which are not or suboptimally reached with current
alhorithms. Its about a navaid hint to help algorithms choose
the right and optimal destination point for a certain object and mode
of transportation.

If its foot and you have a footway to the entrance - Its the entrance.
If there is an explicit car park than its that for the car. If its
by bus you can select the bus stop (in which case you switch mode of
transportation and have your next destination from the navaid relation)

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Navaid relation?

[Florian Lohoff]

Hola Mateusz,

On Wed, May 22, 2019 at 12:26:01AM +0200, Mateusz Konieczny wrote:
> 21 May 2019, 23:46 by f...@zz.de:
> 
> > - Houses which are routeable by road a but are near road b or vice
> >  versa.
> >
> > Adding more roads aka service/driveway does not necessary make it more
> > deterministic.
> >
> Can you give example of residential building with fully mapped roads, footways
> and obstacles where well written router will fail?

- Baumstraße 43a, Gütersloh, Germany
It does not have a connection to Baumstraße but to
Hermann-Vogelsang-Straße.

It still will be routed through Baumstraße and the driveway to
Baumstraße 45a

IMHO unfixable without bending geometry 

- Dalbker Straße 40a, Oerlinghausen, Germany 
  Dalbker Straße 44a, Oerlinghausen, Germany 
Both fixed by moving the Address to a node, moving it further to
Dalkbker Straße within the outline of the Building.

Otherwise you'd be routed to Buchweizenweg without access to
the Building. This is what multiple of my collegues complained
about.

Here i bend geometry until it halfway worked.

Just 2 examples for the last 10 days or so. And footways wont help
you in a car profile. You could bring a footway directly connecting
the entrance to the Street.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Feature Proposal - RFC - juggling spot

[Pablo]

Thx for your answers :). 

I m speaking of juggling as a sport and not as entertainment. These meetings 
are not organised to earn money or to make shows, but to practice and meet each 
other.

I don't know any spaces primarily used for juggling, bukers, scuba diving, 
slack line, or other sport that don't need peculiar infrastructures. (Even ski 
station are not primarily used for ski in summer). So why not use the tag 
leisure = pitch sport=juggling?  And if needed adding another sport=whatever. 

Verifiability : it s only verifiable in the dates where people meet (in winter 
theses places are commonly not used). As, you can't verify the proprieties of a 
shop went it's close. Sometime the address can be find on the website of the 
juggling association or on Facebook groups, sometimes you have to find the 
people who know where and when theses meeting occurs. In any case it can be 
verified but not anytime.

However, this ephemeral  spaces exist and are used. So I think it could be 
usefull to create a maintag "for sport that does not take place on a delimited 
sport field". This wild resolve the problem of the format leisure = pitch sport 
= juggling. Don t you think ?Le 22 mai 2019 00:05, Jmapb  a 
écrit :
>
> On 5/21/2019 3:34 PM, Pablo wrote
> > A new feature proposal which could be very useful for the juggling 
> > community. Usually, jugglers meet in specific spaces in cities (usually 
> > open spaces like parcs). There is often a day of the week which is choose 
> > to meet in priority. It s like a informal sport center. I thinks it s the 
> > same thing for slack lines and acrobatics but I m not sure. Osm could help 
> > find theses spots which is very usefull when you travel. If this tag is 
> > accepted, I will inform the juggling community so they can add their spots.
> > You can find it here :
> > https://wiki.openstreetmap.org/wiki/Proposed_features/juggling_spot
>
> juggling=spot is not a great tag, since it doesn't follow the existing
> tagging conventions. Better would be sport=juggling -- but the sport=*
> tag has to be added to some other physical feature; it's not a valid tag
> all by itself.
>
> If there's a signed or otherwise documented and verifiable place that's
> *primarily* designed/used for juggling, it could be tagged leisure=pitch
> + sport=juggling.
>
> If this use not verifiable by other mappers, the juggling tag will
> probably be deleted.
>
> J
>
> ___
> 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] Navaid relation?

[Jan S]

Am 22. Mai 2019 00:44:51 MESZ schrieb Mateusz Konieczny 
:
>
>22 May 2019, 00:38 by marc_marc_...@hotmail.com:
>
>> Le 22.05.19 à 00:16, Florian Lohoff a écrit :
>>
>>>
>>> Hi marc,
>>>
>>> On Tue, May 21, 2019 at 10:02:53PM +, marc marc wrote:
>>>
 Hello,

 Le 21.05.19 à 23:46, Florian Lohoff a écrit :

> Currently all Routing/Navigation application try hard to find
> the nearest or best point on the routeable network for a given
> destination lat/lon or object.
>

 with best, you mean : only one ? that look like wrong
 a destination can have several points depending on the type
 of locomotion.
 the same type of locomotion can have several points, e.g. several
>ways
 that desert a station by foot, several other for car, ...

>>>
>>> What is the expectation to get navigated to when selecting a park?
>>>
>>
>> there is no such thing as "a single point that makes everyone agree"
>> take the case of a square park fenced by a fence, surrounded by 4 
>> streets each with a pedestrian entrance to the park.
>> those arriving from the north will probably want to stop at the
>street 
>> to the north, while those arriving from the south will probably want
>to 
>> stop at the street at the south entrance.
>> Those who have difficulty walking will probably prefer the car park 
>> closest to an entrance, while others will prefer parking for people
>with 
>> reduced mobility or free parking, all while they have all come by
>car.
>> on the basis of which objective criteria will you decide which point
>of 
>> the public network is most suitable to reach the park?
>>
>Also, some people may drive (bicycle), other may arrive by a public
>transport
>others may walk or drive (by car) etc.
>
>See for example https://www.openstreetmap.org/#map=17/50.06288/19.91742
>
>- a park that has multiple entrances, each may be preferred in some
>situation.

I am also against mapping for navigation purposes. The data shall reflect the 
truth on the ground, all else is up to the programme making use of that data.

In case of a park with multiple entrances (which would obviously have to be 
recognisable by other programmes), it's up to the routing software to route you 
either to the entrance closest to you, the one that's best to be reached given 
the means of transport chosen or maybe offer you a choice of entrances to 
select from.

The same goes for big complexes like airports. Take Madrid Barajas or London 
Heathrow with terminal buildings at different locations, plus a cargo area and 
maybe a general aviation area. Here, you obviously have to chose a specific 
point you want to be routed to, and then the routing software should take you 
to an entry point of that specific place.

I imagine that like on a taxi. If you say "Take me to Heathrow", the driver 
will inevitably ask "Which terminal?". If you say "Take me to Central Park", 
the driver will, again, ask you for a more specific location or make a decision 
for you (the nearest/furthest entry, depending on his/her honesty ;)). These 
very decisions should be made, or these very questions asked by a routing 
programme.

Best, Jan

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