[Tagging] Simple Indoor Tagging

[Peter Barth]

Hi,

starting after the SOTM-EU we've worked hard on a new proposal for 
indoor tagging: Simple Indoor Tagging. The Proposal can be found here:
https://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging

We think that this proposal is simple and holistic at once and ready to
be used. Anyhow, we'd like to hear your opinion if there's something we
missed. Please comment either here, at the proposal's discussion page or
in the original thread in the forum 
(http://forum.openstreetmap.org/viewtopic.php?pid=451544).

Peda

-- 

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

Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

[Dan S]

2014-09-19 15:52 GMT+01:00 Tobias Knerr :
> On 19.09.2014 14:22 Dan S wrote:
>>  for buildings:   building=residential + residential=university + operator=*
>> OR
>>  for sites:   landuse=residential + residential=university + operator=*
>>
>> Note that the same scheme seems to me to work well for building and for 
>> landuse.
>>
>> I thought this had been discussed on tagging recently, but I can't
>> find it, all I can find is the RFC for amenity=dormitory, currently
>> used 263 times. (I will add that "dormitory" is certainly a little odd
>> from a British English point of view, notwithstanding the comments
>> already made to the RFC.)
>
> That proposal now suggests amenity=student_accommodation, precisely
> because of the oddness involved with the term "dormitory".

Ah yes, thanks. So now it assumes the occupants are students and not
lecturers ;)

(I'm just being cheeky. I know of universities in which lecturers do
stay in similar accommodation blocks, but that point is not important
enough to argue about...)

> Personally, I prefer using the amenity key rather than building or
> landuse. Landuse lacks the implication that this is one distinct
> facility

OK. I understand why you'd prefer amenity for tagging the usage. If
that tag gets accepted I guess I should use that instead of landuse,
and I understand your arguments there. I feel differently, because I
feel the analogy between a "housing estate" and a multi-building
"student halls" site is quite a strong analogy, neatly represented by
a named area of landuse=residential. But there we go.

> and building values are not supposed to represent usage, but how the building 
> is built.

This week I stayed in university accommodation (even though I'm not a
student ;), and the buildings were purpose-built student halls, so it
would be nice to tag the building appropriately. Alternatives include:
(a) "building=residential" (without subtagging), which is fine if vague;
(b) "building=apartments", which is tolerable but not quite appropriate;
(c) "building=dormitory" which is in use, but it's US English, and to
my Brit English mind just feels wrong. Sorry to moan about the US/UK
difference, but it is indeed a difference:
,

(d) "building=residential + residential=university", the approach I
was using recently. Not as widely used. It has an advantage of
graceful fallback (meaning data-users can understand the objects as
building=residential even if they ignore the subtag).

I still prefer (d) though if building=dormitory becomes widely
accepted then I guess I shall have to swallow that loss for British
english!

Cheers
Dan

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

Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

[sabas88]

On 19 Sep 2014 16:54, "Tobias Knerr"  wrote:
>
> On 19.09.2014 14:22 Dan S wrote:
> >  for buildings:   building=residential + residential=university +
operator=*
> > OR
> >  for sites:   landuse=residential + residential=university + operator=*
> >
> > Note that the same scheme seems to me to work well for building and for
landuse.
> >
> > I thought this had been discussed on tagging recently, but I can't
> > find it, all I can find is the RFC for amenity=dormitory, currently
> > used 263 times. (I will add that "dormitory" is certainly a little odd
> > from a British English point of view, notwithstanding the comments
> > already made to the RFC.)
>
> That proposal now suggests amenity=student_accommodation, precisely
> because of the oddness involved with the term "dormitory".
>
> Personally, I prefer using the amenity key rather than building or
> landuse. Landuse lacks the implication that this is one distinct
> facility, and building values are not supposed to represent usage, but
> how the building is built.
>
+1
I tagged some student residences as tourism=guest_house previously, but
they aren't buildings (some are apartments inside buildings, but owned by
the local government agency for student services).

Stefano
> ___
> 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] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

[phil]

Students accommodation is neither tourism or guesthouse,  I would have gone for 
hall_of_residence. 

Phil (trigpoint )

On Sat Sep 20 2014 14:46:17 GMT+0100 (BST), sabas88 wrote:
> On 19 Sep 2014 16:54, "Tobias Knerr"  wrote:
> >
> > On 19.09.2014 14:22 Dan S wrote:
> > >  for buildings:   building=residential + residential=university +
> operator=*
> > > OR
> > >  for sites:   landuse=residential + residential=university + operator=*
> > >
> > > Note that the same scheme seems to me to work well for building and for
> landuse.
> > >
> > > I thought this had been discussed on tagging recently, but I can't
> > > find it, all I can find is the RFC for amenity=dormitory, currently
> > > used 263 times. (I will add that "dormitory" is certainly a little odd
> > > from a British English point of view, notwithstanding the comments
> > > already made to the RFC.)
> >
> > That proposal now suggests amenity=student_accommodation, precisely
> > because of the oddness involved with the term "dormitory".
> >
> > Personally, I prefer using the amenity key rather than building or
> > landuse. Landuse lacks the implication that this is one distinct
> > facility, and building values are not supposed to represent usage, but
> > how the building is built.
> >
> +1
> I tagged some student residences as tourism=guest_house previously, but
> they aren't buildings (some are apartments inside buildings, but owned by
> the local government agency for student services).
> 
> Stefano
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>

-- 
Sent from my Jolla
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

[fly]

Am 20.09.2014 18:32, schrieb p...@trigpoint.me.uk:
> Students accommodation is neither tourism or guesthouse,

+1

>  I would have gone for hall_of_residence. 

Do not know if hall_of_residence is the right term.

I know this accommodations for staff of hospitals (nurses) , too.

Would be nice if could find some tag to describe it without profession.

cu fly

> On Sat Sep 20 2014 14:46:17 GMT+0100 (BST), sabas88 wrote:
>> On 19 Sep 2014 16:54, "Tobias Knerr"  wrote:
>>>
>>> On 19.09.2014 14:22 Dan S wrote:
  for buildings:   building=residential + residential=university +
>> operator=*
 OR
  for sites:   landuse=residential + residential=university + operator=*

 Note that the same scheme seems to me to work well for building and for
>> landuse.

 I thought this had been discussed on tagging recently, but I can't
 find it, all I can find is the RFC for amenity=dormitory, currently
 used 263 times. (I will add that "dormitory" is certainly a little odd
 from a British English point of view, notwithstanding the comments
 already made to the RFC.)
>>>
>>> That proposal now suggests amenity=student_accommodation, precisely
>>> because of the oddness involved with the term "dormitory".
>>>
>>> Personally, I prefer using the amenity key rather than building or
>>> landuse. Landuse lacks the implication that this is one distinct
>>> facility, and building values are not supposed to represent usage, but
>>> how the building is built.
>>>
>> +1
>> I tagged some student residences as tourism=guest_house previously, but
>> they aren't buildings (some are apartments inside buildings, but owned by
>> the local government agency for student services).
>>
>> Stefano
>>> ___
>>> 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 - Tagging for complex junctions or traffic signals that are named

[fly]

Am 20.09.2014 02:03, schrieb johnw:
> So the solution for a complex intersection is to have a signal_area area
> with an outline that intersects with all the nodes where the signal
> would affect the traffic? This would let the renderer use one icon, and
> still have the ways marked in the proper spot for the intersection,
> right? (assuming they will support signal_area).

Not sure if the single traffic_signals node need to be parent of the
area but they should be at least within the area as a hint for the renderer.

Thanks for considering some extra tag(-combinations) for the area.

cu fly


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

Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

[Richard Welty]

On 09/20/2014 12:41 PM, fly wrote:

Am 20.09.2014 18:32, schrieb p...@trigpoint.me.uk:

  I would have gone for hall_of_residence.

Do not know if hall_of_residence is the right term.


hall_of_residence would work. i would have proposed the
shorter, less formal term residence_hall which is what you
will find in US usage.

richard


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

Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

[Martin Koppenhoefer]

> Il giorno 20/set/2014, alle ore 13:47, Dan S  ha 
> scritto:
> 
> I still prefer (d) though if building=dormitory becomes widely
> accepted then I guess I shall have to swallow that loss for British
> english!


I'm also for a specific value, if dormitory doesn't hit it for the British, 
maybe there is an analog term?


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

Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

[Lukas Sommer]

Okay, I’ve adapted the proposal wiki page.

We can propose to tag complex traffic signal areas _only_ using the area,
and not to tag the individual traffic signals. That makes it easier for
renderers to display only one icon per traffic signal area. However, I feel
we should not completly exclude for all time the possibility to tag also
the individual traffic signals – it is at least a valid information, even
if it is not necessary for traditional japanese maps. The individual
traffic signals are simple nodes that are located within the area. We would
not make it a rule, but just recommand to _not_ tag the individual traffic
signals for Japan.

As described in the proposal, the area is simply drawn around the
approximative area that is affected by the traffic signals. It encloses
everything, but shares nodes only with the incoming and outgoing highways.

Lukas Sommer

2014-09-20 16:45 GMT+00:00 fly :

> Am 20.09.2014 02:03, schrieb johnw:
> > So the solution for a complex intersection is to have a signal_area area
> > with an outline that intersects with all the nodes where the signal
> > would affect the traffic? This would let the renderer use one icon, and
> > still have the ways marked in the proper spot for the intersection,
> > right? (assuming they will support signal_area).
>
> Not sure if the single traffic_signals node need to be parent of the
> area but they should be at least within the area as a hint for the
> renderer.
>
> Thanks for considering some extra tag(-combinations) for the area.
>
> cu fly
>
>
> ___
> 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] New key proposal - paved=yes/no

[Tomasz Kaźmierczak]

Hello all,
I've posted the below message on the forum[1],  and have been directed from 
there to this mailing list, thus re-posting it.
*Idea*
I would like to suggest making the *paved* key for highways (and probably other 
types of elements) official. Taginfo for *paved*:

http://taginfo.openstreetmap.org/keys/paved#values[2]
The above shows that the key is already being used, but the Wiki doesn't 
describe this key, instead redirecting Key:paved to the article about 
Key:surface.
*Rationale*
Currently, the *surface* key is being used as a way of saying that a given 
*highway* is paved or unpaved, but often the value for the *surface* key is not 
a generic /paved/ or /unpaved/, but a specific surface type is given.This is of 
course very useful for describing the particular surface type a given highway 
has. However, in some cases, a simple information on just whether a highway is 
paved or not, would be very useful. One such case would be navigation software 
– if a user chooses to avoid unpaved roads, the software can check the value of 
the *surface* key, but in practice most (all?) of the navigation software only 
checks for a subset of all the possible values the *surface* key can have. This 
leads to incorrect (in terms of what the user expects) navigation when, for 
example, the *surface* is set to some value that describes an unpaved road, not 
recognized by the navigation software – if the software assumes that all 
*highway*s are paved, unless explicitly stated otherwise (by recognized values 
of known keys), then, in consequence, it assumes that the road in question is 
paved.
If the *paved* key was widely used, then the navigation software would have a 
simple and clear way of checking whether a given road is paved or not. The 
default value of the *paved* key for *highway*s could be /yes/, so that it 
would be consistent with the assumption that *highway*s in general are paved.
I don't mean that we should stop using the /paved/ and /unpaved/ values for the 
*surface* key – I'm sure those generic values are useful in some cases. 
However, using the *paved* key would be also very useful. Also, the 
*surface*=/paved/ could also implicate *paved*=/yes/ and similarly 
*surface*=/unpaved/ could implicate *paved*=/no/, so that duplication of the 
information could be avoided when the generic /paved/ and /unpaved/ values are 
set for the *surface* key.
I believe that adding an article for the *paved* key to the Wiki would 
encourage people to use this tag, and navigation software makers to implement 
support for it in their applications.
What do you think about that? 

Regards,
Tomek


[1] http://forum.openstreetmap.org/viewtopic.php?pid=451593
[2] http://taginfo.openstreetmap.org/keys/paved#values
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Richard Welty]

On 09/20/2014 05:42 PM, Tomasz Kaźmierczak wrote:
I would like to suggest making the paved key for highways (and 
probably other types of elements) official. Taginfo for paved:


http://taginfo.openstreetmap.org/keys/paved#values

The above shows that the key is already being used, but the Wiki 
doesn't describe this key, instead redirecting Key:paved to the 
article about Key:surface.





-1

duplicative

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

Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

[Eugene Alvin Villar]

On 9/20/14, Dan S  wrote:
> 2014-09-19 15:52 GMT+01:00 Tobias Knerr :
> I still prefer (d) though if building=dormitory becomes widely
> accepted then I guess I shall have to swallow that loss for British
> english!

Wouldn't be the first time if ever:
http://wiki.openstreetmap.org/wiki/Tag:sport%3Dsoccer

That said, to me dormitories may also apply to other institutionalized
housing such as housing for staff of a manufacturing plant. Although I
admit that dormitories are primarily for students in my understanding.
This ambiguity can be resolved by careful definition in the Wiki if
ever people accept *=dormitory.

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

Re: [Tagging] New key proposal - paved=yes/no

[Paul Johnson]

On Sat, Sep 20, 2014 at 4:59 PM, Richard Welty 
wrote:

>
> On 09/20/2014 05:42 PM, Tomasz Kaźmierczak wrote:
>
> I would like to suggest making the paved key for highways (and probably
> other types of elements) official. Taginfo for paved:
>
> http://taginfo.openstreetmap.org/keys/paved#values
>
> The above shows that the key is already being used, but the Wiki doesn't
> describe this key, instead redirecting Key:paved to the article about
> Key:surface.
>
>
> -1
>
> duplicative
>
>
Seconded
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

[phil]

Dormitories are rooms with multiple beds, usually bunk beds and associated with 
youth hostels,  certainly not suitable for student accommodation where there is 
typically one student in a room, maybe two but they are certainly not 
dormitories. 

Phil (trigpoint )

On Sat Sep 20 2014 23:12:24 GMT+0100 (BST), Eugene Alvin Villar wrote:
> On 9/20/14, Dan S  wrote:
> > 2014-09-19 15:52 GMT+01:00 Tobias Knerr :
> > I still prefer (d) though if building=dormitory becomes widely
> > accepted then I guess I shall have to swallow that loss for British
> > english!
> 
> Wouldn't be the first time if ever:
> http://wiki.openstreetmap.org/wiki/Tag:sport%3Dsoccer
> 
> That said, to me dormitories may also apply to other institutionalized
> housing such as housing for staff of a manufacturing plant. Although I
> admit that dormitories are primarily for students in my understanding.
> This ambiguity can be resolved by careful definition in the Wiki if
> ever people accept *=dormitory.
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

-- 
Sent from my Jolla
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Tod Fitch]

On Sep 20, 2014, at 4:00 PM, Paul Johnson wrote:

> 
> On Sat, Sep 20, 2014 at 4:59 PM, Richard Welty  wrote:
> 
> On 09/20/2014 05:42 PM, Tomasz Kaźmierczak wrote:
>> I would like to suggest making the paved key for highways (and probably 
>> other types of elements) official. Taginfo for paved:
>> http://taginfo.openstreetmap.org/keys/paved#values
>> 
>> The above shows that the key is already being used, but the Wiki doesn't 
>> describe this key, instead redirecting Key:paved to the article about 
>> Key:surface.
>> 
>> 
> 
> -1 
> 
> duplicative
> 
>  
> Seconded 

It might be considered duplicative, but what should a data consumer do if 
confronted with a surface=* value that is unknown to it (and the wiki)? We 
aren't talking human intelligence here where an informed guess is possible. 
Should such a way be considered paved or unpaved for purposes of routing? From 
that point of view, Richard's proposal gives a lot of clarity.

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

Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

[Eugene Alvin Villar]

On Sun, Sep 21, 2014 at 7:09 AM,  wrote:

> Dormitories are rooms with multiple beds, usually bunk beds and associated
> with youth hostels,  certainly not suitable for student accommodation where
> there is typically one student in a room, maybe two but they are certainly
> not dormitories.
>

What you're saying is British English usage. Here in the Philippines,
dormitories are understood to be buildings primarily for students.

For example, in the Ateneo de Manila University, we have the Cervini
Residence Hall for males and Eliazo Residence Hall for females: Note that
the Wikipedia article classifies these are "dormitories" in accordance to
local usage even if the official name uses "Residence Hall":
https://en.wikipedia.org/wiki/Cervini-Eliazo_Residence_Halls

In the University of the Philippines, we have several dormitories such as
Kalayaan Hall, Ilang-Ilang Hall, Molave Hall, etc.

There are also private businesses that run student dormitories, usually
located very near universities such as Manila Dormitory across the
University of Santo Tomas: http://maniladormitory.com/
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Paul Johnson]

On Sat, Sep 20, 2014 at 6:15 PM, Tod Fitch  wrote:
>
> It might be considered duplicative, but what should a data consumer do if
> confronted with a surface=* value that is unknown to it (and the wiki)? We
> aren't talking human intelligence here where an informed guess is possible.
> Should such a way be considered paved or unpaved for purposes of routing?
> From that point of view, Richard's proposal gives a lot of clarity.
>

Same way as if the surface tag was missing.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Tom Pfeifer]

-1, because:

Tomasz Kaźmierczak wrote on 2014-09-20 23:42:

I would like to suggest making the paved key for highways (and probably other 
types of elements) official.
Taginfo for paved:
http://taginfo.openstreetmap.org/keys/paved#values

The above shows that the key is already being used,


1648 times, compared to 9383813 of 'surface'.


but the Wiki doesn't describe this key, instead redirecting Key:paved
to the article about Key:surface.


to discourage the use of a duplicate key


However, in some cases, a simple information on just whether a highway is paved 
or not, would be very useful.
One such case would be navigation software – if a user chooses to avoid unpaved 
roads,


Navigation software is pretty able to consider a short list of specific pavings
as 'paved' and another short list as 'unpaved', they are already structured in 
the
wiki.

OsmAnd, as a popular navigation software, does so, and in the pre-1.9 nightlies 
you
can switch on colour coding for different surfaces.


the software can check the value of the surface key, but in practice most (all?)
of the navigation software only checks for a subset of all the possible values
the surface key can have.


Could you please support your argument with examples of such software, and
why such incompleteness cannot be fixed within the router/renderer?


If the paved key was widely used, then the navigation software would have a 
simple
and clear way of checking whether a given road is paved or not.


Not much simpler than checking for a member of a list.


The default value
of the paved key for highways could be yes, so that it would be consistent with 
the
assumption that highways in general are paved.


This does not work as a general assumption.
I would assume a motorway as paved, but a track or path as unpaved, unless 
shown otherwise.


Also, the surface=paved could also implicate paved=yes
and similarly surface=unpaved could implicate paved=no, so that duplication of 
the
information could be avoided when the generic paved and unpaved values are set 
for the surface key.


You are just arguing against your proposal. As we have surface=paved
we don't need paved=yes. And surface=asphalt implies paved.

Tod Fitch wrote on 2014-09-21 01:15:
> It might be considered duplicative, but what should a data consumer do if 
confronted
> with a surface=* value that is unknown to it (and the wiki)? We aren't 
talking human
> intelligence here where an informed guess is possible. Should such a way be 
considered
> paved or unpaved for purposes of routing? From that point of view, Richard's 
proposal gives a lot of clarity.

You would not want to add 9383813 unnecessary paved=yes/no just to cover
a few dozen undocumented values for surface, most of them probably typos.



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

Re: [Tagging] New key proposal - paved=yes/no

[David Bannon]

yes, agree strongly. Surface= is a good tag, provides important info but
it is far too fine grained. Someone setting up a route cannot be
expected to sift through all the possible values.

Similarly, we may well have a chance to get the renderers to respect a
clear, on/off tag like the proposed and show it on the maps too.

I see no problem with both tags being used.

I think sometimes we put too much detail in the database and risk making
the data unusable because of that. Mention making the data usable, we
see charges of "tagging for the renderer". But this is important, I have
detailed life threatening issues resulting from unclear maps. This
proposal will provide valuable, dare I say "usable" info for consumers !

David

On Sat, 2014-09-20 at 23:42 +0200, Tomasz Kaźmierczak wrote:
> Hello all,
> 
> I've posted the below message on the forum, and have been directed
> from there to this mailing list, thus re-posting it.
> 
> Idea
> 
> I would like to suggest making the paved key for highways (and
> probably other types of elements) official. Taginfo for paved:
> http://taginfo.openstreetmap.org/keys/paved#values
> 
> The above shows that the key is already being used, but the Wiki
> doesn't describe this key, instead redirecting Key:paved to the
> article about Key:surface.
> 
> Rationale
> 
> Currently, the surface key is being used as a way of saying that a
> given highway is paved or unpaved, but often the value for the surface
> key is not a generic paved or unpaved, but a specific surface type is
> given.This is of course very useful for describing the particular
> surface type a given highway has. However, in some cases, a simple
> information on just whether a highway is paved or not, would be very
> useful. One such case would be navigation software – if a user chooses
> to avoid unpaved roads, the software can check the value of the
> surface key, but in practice most (all?) of the navigation software
> only checks for a subset of all the possible values the surface key
> can have. This leads to incorrect (in terms of what the user expects)
> navigation when, for example, the surface is set to some value that
> describes an unpaved road, not recognized by the navigation software –
> if the software assumes that all highways are paved, unless explicitly
> stated otherwise (by recognized values of known keys), then, in
> consequence, it assumes that the road in question is paved.
> 
> If the paved key was widely used, then the navigation software would
> have a simple and clear way of checking whether a given road is paved
> or not. The default value of the paved key for highways could be yes,
> so that it would be consistent with the assumption that highways in
> general are paved.
> 
> I don't mean that we should stop using the paved and unpaved values
> for the surface key – I'm sure those generic values are useful in some
> cases. However, using the paved key would be also very useful. Also,
> the surface=paved could also implicate paved=yes and similarly
> surface=unpaved could implicate paved=no, so that duplication of the
> information could be avoided when the generic paved and unpaved values
> are set for the surface key.
> 
> I believe that adding an article for the paved key to the Wiki would
> encourage people to use this tag, and navigation software makers to
> implement support for it in their applications.
> 
> What do you think about that? 
> 
>  
> 
> Regards,
> 
> Tomek
> 
> ___
> 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 - Tagging for complex junctions or traffic signals that are named

[johnw]

On Sep 21, 2014, at 5:13 AM, Lukas Sommer  wrote:

> As described in the proposal, the area is simply drawn around the 
> approximative area that is affected by the traffic signals. It encloses 
> everything, but shares nodes only with the incoming and outgoing highways.

So the nodes where the signals_area intersects the highways is where the 
signals would normally be mapped for complex intersections? Sounds like an even 
simpler solution.


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

Re: [Tagging] Simple Indoor Tagging

[Dave Swarthout]

This looks like a great piece of work. Thank you for your efforts.

I would like to suggest somehow adding access to your proposal (as a level
subkey?). Many times there are levels in a building that are restricted for
one reason or another and it would help to know which these are. From the
examples it would seem there is a way to add a name to a level but it's not
clear to me how one would go about tagging it. Access could be added in a
similar fashion.

Cheers,

Dave

On Sat, Sep 20, 2014 at 5:11 PM, Peter Barth  wrote:

> Hi,
>
> starting after the SOTM-EU we've worked hard on a new proposal for
> indoor tagging: Simple Indoor Tagging. The Proposal can be found here:
> https://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging
>
> We think that this proposal is simple and holistic at once and ready to
> be used. Anyhow, we'd like to hear your opinion if there's something we
> missed. Please comment either here, at the proposal's discussion page or
> in the original thread in the forum (
> http://forum.openstreetmap.org/viewtopic.php?pid=451544).
>
> Peda
>
> --
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Simple Indoor Tagging

[Matthijs Melissen]

On 20 September 2014 11:11, Peter Barth  wrote:
> starting after the SOTM-EU we've worked hard on a new proposal for
> indoor tagging: Simple Indoor Tagging. The Proposal can be found here:
> https://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging

Thanks for your efforts. Two points:

- Should the level tags be subsequent numerical values, or the level
names signposted in the building (for instance in the lifts)? In
England, levels are often named basement/lower ground/upper ground
floor. In Germany, I have seen buildings that distinguish floor 0 and
floor -0. If a building starts with for instance Ground, Mezzanine,
Floor 1, Floor 2, then it might be confusing to use levels 0, 1, 2, 3
for that, as then each level key would be off by one with the signed
level. Why not use level for signposted levels and layer for a
numerical order?

- What is the reason for using indoor=corridor rather than
highway=footway and stairs=* rather than highway=steps? Can a way have
both tags? Sometimes routing through shopping malls is optimal even
for long-distance foot routing, so it would be nice if regular routers
could keep make use of such footways.

-- Matthijs

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

[Tagging] (Soapy) Massage Parlour

[Mishari Muqbil]

Hi,

Thailand has these places called "entertainment complexes"[1]  that
offers bathing + massage services and quite often the expectation is
that there will be sexual services offered. However, I don't want to tag
them as brothels as prostitution on the premises is legally not allowed[2].

I propose to tag this as leisure=massage_parlour since that's what the
Thai English dictionary calls them[3] but I don't want it to be mistaken
for more family friendly establishments in other parts of the world.
Colloquially these places are called soapy massage so perhaps
leisure=soapy_massage? :)

One reason why they should be mapped is just how prominent they are as
landmarks in general. For example, here's one called Utopia
http://www.mapillary.com/map/im/z1A8OOUw01E5Jc84Mff-1Q this one's La
Defense http://www.mapillary.com/map/im/ho84IFdUxupke-6pwrWW3g and
Colonze http://www.mapillary.com/map/im/469ttdMVw4_1o3vkuvE_xw

Any thoughts?

[1] https://en.wikipedia.org/wiki/Prostitution_in_Thailand#Ab_Ob_Nuat
[2]
https://en.wikipedia.org/wiki/Prostitution_in_Thailand#The_Entertainment_Places_Act
[3]
http://th.w3dictionary.org/index.php?q=%E0%B8%AA%E0%B8%96%E0%B8%B2%E0%B8%99%E0%B8%AD%E0%B8%B2%E0%B8%9A%E0%B8%AD%E0%B8%9A%E0%B8%99%E0%B8%A7%E0%B8%94
-- 
Best regards
Mishari Muqbil
EE32 64BD 7D1F 5946

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

Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

[Lukas Sommer]

> So the nodes where the signals_area intersects the highways is where the
signals would normally be mapped for complex intersections?

Not exactly. It would be difficult to do so if you have really complex
junctions with really many individual traffic signals and you want to catch
all of them – a zickzack that is not easy to draw and not practical to
maintain. The area is drawn just _around_ everything that is considered the
junction.

About the individual traffic signals. We recommand as current best-practice
to not map them if you use the area. Means: Don’t do both things. (But
maybe in the future this could be considered useful and it could be done
without breaking the tagging scheme just like every other normal traffic
signal with highway=traffic_signals on a node.)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging