Re: [Tagging] Vegan "cheese" shops

[Andrew Errington]

It's a bit runny...

On 19/12/2019, Martin Koppenhoefer  wrote:
>
>
> sent from a phone
>
>> On 18. Dec 2019, at 21:10, Philip Barnes  wrote:
>>
>> Calling something that is not made from milk cheese is I think illegal in
>> the UK.
>
>
> what about “vegan milk” then? ;-)
>
>  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] emergency=no on hospitals is ambiguous

[Andrew Errington]

We have a local hospital. It is tiny and has no emergency room.

Andrew

On 03/11/2019, Francesco Ansanelli  wrote:
> Hello list,
>
> I don't know is anybody wrote about this before, but I have noticed that
> the emergency tag changes meaning on hospitals and the result is weird:
> emergency tag indicate whether an emergency vehicle has access to the
> way/point, but on hospitals his value is about emergency rooms.
> I cannot imagine an hospital that disallowed access to emergency vehicles,
> but the editors by example forgot about this and indicate so...
> To avoid any ambiguity a rename could clarify the situation:
> emergency -> emergency_room
> On every hospital and we can assume emergency=yes on them (it's hard to me
> to imagine a place that is emergency=no btw).
> What do you think?
> Cheers,
> Francesco
>

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

Re: [Tagging] units and notations for maxstay

[Andrew Errington]

Nope. No tag means not applicable, or not known. Otherwise we'd have to tag
every object with every tag (mostly all set to 'no').

Andrew

On Fri, Feb 22, 2019, 08:33 Tony Shield  No Tag means don't know, any tag value means its been checked and this is
> the value.
>
> TonyS
> On 21/02/2019 19:15, Andrew Errington wrote:
>
> If there is no limit then omit the maxstay tag. No tag, no limit.
>
> Andrew
>
> On Fri, Feb 22, 2019, 07:47 Tobias Knerr 
>> On 20.02.19 00:08, Warin wrote:
>> > 24/7 is used for opening hours - so for consistency I would tend to go
>> > for that.
>>
>> Maxstay values are durations, opening_hours values (such as "24/7")
>> refer to time intervals. Those are separate concepts, so I don't think
>> consistency is called for.
>>
>> If we want an explicit value for unlimited duration, I recommend
>> "unlimited". It's a simple and unambiguous solution.
>>
>> Tobias
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://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] units and notations for maxstay

[Andrew Errington]

If there is no limit then omit the maxstay tag. No tag, no limit.

Andrew

On Fri, Feb 22, 2019, 07:47 Tobias Knerr  On 20.02.19 00:08, Warin wrote:
> > 24/7 is used for opening hours - so for consistency I would tend to go
> > for that.
>
> Maxstay values are durations, opening_hours values (such as "24/7")
> refer to time intervals. Those are separate concepts, so I don't think
> consistency is called for.
>
> If we want an explicit value for unlimited duration, I recommend
> "unlimited". It's a simple and unambiguous solution.
>
> 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

Re: [Tagging] units and notations for maxstay

[Andrew Errington]

On Thu, Feb 21, 2019, 01:44 Colin Smale  Lets be clear, the storage format can (and should) be decoupled from the
> display format. What is stored in the database can easily (assuming it is
> sufficiently standardised!!!) be translated for human consumption, and the
> inverse can be done when storing. It happens in just about every computer
> program ever. Storing the value as an ISO string assures
> machine-readability and editors, browsers etc can use standard libraries to
> format it for humans, in whatever language you like.
>

Precisely this. Glad somebody gets it.

It's the same argument that we had over 'potable=yes'.

Amazingly, everyone here understands the ISO8601 concept and how it can be
used, but we assume nobody else does, therefore our hands are tied and we
can't use it.

If we think people won't enter the data correctly then create a little
tool, much like the opening hours tool in Osmand, that makes it easy. The
UI presents the data in a human-readable format (bonus points for
localisation on the fly) but records the data in the database in ISO8601
format (language and location agnostic). Similarly, if current query tools
can't handle this format then... update the tools.

Power users can simply read the data directly. New power users will be
grateful that we chose a sensible data format for this key.

I'll be interested to see the details of alternative proposals, but I doubt
they'll be as succinct.

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

Re: [Tagging] units and notations for maxstay

[Andrew Errington]

Already handled by ISO8601:

https://en.m.wikipedia.org/wiki/ISO_8601#Durations

I think any discussion of dates and times should start by asking if we
could apply ISO8601 to the problem at hand. For example the other thread
about start date variants.

 Andrew

On Wed, Feb 20, 2019, 12:48 Warin <61sundow...@gmail.com wrote:

> On 20/02/19 10:32, Paul Allen wrote:
>
> On Tue, 19 Feb 2019 at 23:16, Warin <61sundow...@gmail.com> wrote:
>
>> On 19/02/19 22:03, Paul Allen wrote:
>>
>> On Tue, 19 Feb 2019 at 03:48, Warin <61sundow...@gmail.com> wrote:
>>
>>> Nothing I could see on the wiki for this. So some guidance would be good.
>>>
>>> Units.
>>>
>>
>> I added a maxstay a few weeks ago and I found info about units at
>> https://wiki.openstreetmap.org/wiki/Key:maxstay
>>
>> Units are not explicitly defined, but there are several examples.  Units
>> in those examples
>> are minutes, hours, and days.  I expect that weeks, months and years
>> would also be
>> acceptable for long-stay parking.  Maybe even decades and centuries,
>> should they be
>> needed.  Seconds are too small to be practicable.
>>
>> No information on default units.
>>
>
> True.  But the examples show which units are permissible and how they
> should be
> specified.
>
> There are some numerical values in the data base without units ... from
>> those values I would guess hours, but they could be days.
>>
>
> Or minutes, depending on actual value.  One place near me says waiting is
> limited to 90 minutes.
> But 90 days is close to 3 months.  Could be either if units aren't given.
>
> As there is no documentation 'we' could make a decision.
>>
>> No information on abbreviations.
>>
>
> From the examples, unit names are spelled out in full.
>
> So the choice is between:
>
>   1) Spelling units in full (as per the examples) and specifying which
> unit is the default.
>
>   2) Coming up with abbreviations and specifying which unit is the default.
>
> I'd go with 1).  Firstly, somebody (like me) may have specified units that
> way already.
> Secondly, different languages may have different names for those units of
> time.  We can
> agree to (mostly) use SI units for mass and length because those are
> applicable in much
> of the world and have standard abbreviations.  Common time units like
> minute, hour and
> month probably have different abbreviations in different parts of the
> world.  Less error
> prone if an editor drop-down has minutes/hours/days than m/h/d if "d" is
> the abbreviation
> for a period of 3600 seconds in some language.  Thirdly, minutes and
> months (m and m).
>
> Looks good to me. See what others think.
>
> On default units ..
> Possibly specify the smallest unit as that will cause the least amount of
> harm with already entered values?
> By that I mean a value of '60' if taken as days would be more harmful to
> the user (fines, tow away) than if taken as minutes.
> Not convinced on this, but it is a thought.
>
> ___
> 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] name with name:en

[Andrew Errington]

I'd suggest leaving it alone. How do you know what language name=* is? How
do you know that it is acceptable to display name=* when language "en" is
requested? They may look identical, but if I request name:en then I'd like
to see name:en if it's present.

This problem comes up time and again, and it's not helpful to delete data
just for the sake of it. Database "bloat" is a canard.

Andrew

On Nov 16, 2017 9:43 AM, "Nelson A. de Oliveira"  wrote:

On Wed, Nov 15, 2017 at 6:34 PM, Warin <61sundow...@gmail.com> wrote:
> There looks to be a duplication taking place (map.me problem ?) where both
> the name=* tag and name:en (the local language)=* are being entered as the
> same value.

There is an old discussion about this at
https://github.com/mapsme/omim/issues/4149

___
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] "Living street" in Japan

[Andrew Errington]

I have a feeling that "living street" is being interpreted as "a street
that people live on", which really should be "residential".  Perhaps you
could ask the mapper for the reason behind the edits, and ask someone to
translate the "living street" wiki page to indicate clearly what it means
(in Japanese) and what it doesn't mean.

Best wishes,

Andrew

On Mar 29, 2017 3:49 PM, "John Willis"  wrote:

As I have been coming back to tagging recently, I noticed a lot of rural
residential/alley/driveway/track roads being mapped as a “living street” in
my region of Japan.

A prolific editor (2000+ edits) is one of the mappers doing it, so I Im
unsure about what is going on.

As far as I know, “living street” is a legal definition for some roads
found in Europe, and not for Japan.

The english/Japanese “Japan Tagging” page offers no suggestion for using
Living Street.
https://wiki.openstreetmap.org/wiki/Japan_tagging

Is this an error of a single user, or is this some systemic regional
tagging change that is not documented?

either way, there is some corrections to be made.

Javbw.

___
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] How might we best map emergency helicopter landing zones?

[Andrew Errington]

I tag them as aeroway=helipad, and it looks like this:
http://www.openstreetmap.org/#map=16/35.2932/127.5317

There are a lot of them in the mountains of Korea.  Usually marked out with
a pattern of white stones embedded in the ground.

Would like to know if there's a better way, or if doing it this way is
wrong.  Or right.

Thanks,

Andrew

On Nov 22, 2016 8:41 PM, "Blake Girardot"  wrote:

> Dear friends,
>
> I have worked with folks doing ground surveys of helicopter landing
> zones during emergency response.
>
> These are ground truthed locations, observed by active search and
> rescue helicopter pilots collecting the basic minimum critical ground
> survey items for an HLZ for their aircraft type.
>
> They collect the data and provide it in the public domain and I would
> like to map it.
>
> I think the vast majority of the items collected are already well
> supported in OSM, trees, light poles, ground type, area, grade,
> landuse.
>
> What would be the best way to map this data? Does it need its own
> namespace? Just map  regular OSM tagging and render the data myself
> custom?
>
> I think issues of does the data belong in OSM are separate issues, I
> am just interested in how to map it and tag it well. I would be
> mapping nothing but ground truthed data that we already map every day,
> trees and light poles and ground type, landuse. It is publicly
> available data (CC0).
>
> Other data could and should be added specific to HLZ's so we will need
> to discuss any non traditional tags that I would like to see be used
> for the HLZs mapped.
>
> Cheers,
> Blake
>
> ___
> 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] Multiple values for one key - the cuisine problem.

[Andrew Errington]

Surely this is a solved problem?  Separate multiple values with a semicolon.

And there is no need for a language code for this type of key.  The values
in the key should be translated by whatever application is using it before
presenting it to the user.  That's why cuisine=french is correct because
the application should change it to "French" before displaying it to an
English-speaking end user.

Best wishes,

Andrew


On 25 August 2016 at 13:18, André Pirard  wrote:

> On 2016-08-24 22:06, Marc Zoutendijk wrote:
>
> How to tag multiple values for a key? The cuisine problem.
>
> Whenever we tag a restaurant, we also have the option of tagging the 
> kind/style of food that is offered:
>
> amenity=restaurant
> cuisine=french
> ...
>
> BTW, the correct English spelling is
>
> cuisine=French
>
> I saw that the OSM people are very picky about correct spelling.
>
> Cheers
> Cordialement,
>
> André.
>
>
> ___
> 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] Layer and highway=steps

[Andrew Errington]

The direction of the way was discussed a long time ago.  Consensus was that
it should be 'up' based on the convention of architectural drawings.  It
seemed as good a reason as any.

That's all I have, really.

Andrew
On 2 Jul 2016 20:48, "Bjoern Hassler"  wrote:

> Hi Volker,
>
> My question does relate to overlapping steps, see
> http://overpass-turbo.eu/s/h5F for context (King's Cross underground,
> London). Yes, layer rather than level.
>
> I'm thinking about accessibility, as well as ease of mapping. Suppose you
> are at a certain location, how do you determine what
> steps/escalators/elevators connect to that location (from other floors)? In
> other words, what are your access options to that layer.
>
> Similarly for mapping: because of the extensive network, it's hard to see
> what's what. With layer on steps you could examine the data layer by layer.
> If only footways have layers, what overpass query would you use to include
> steps?
>
> Thanks for note on up/down. The wiki documentation does suggest this: "By
> convention, the *direction of the way* should preferably point uphill,
> but the key incline =* should
> always be added to the way (see the talk
> page
> for more
> details)." So no default direction as you say, but convention and
> recommended incline tag.
>
> Bjoern
> On 2 Jul 2016 12:04, "Volker Schmidt"  wrote:
>
>> "layer" is not relevant here. The "layer" tag is only used to indicate
>> the relative vertical position of the object with respect to other objects.
>> So steps would only have a layer tag if they are crossing another way, but
>> not connecting to it.
>>
>> To indicate the up or down direction of steps, you can use the tag
>> incline=up|down. There is no default direction of steps, as far a I know.
>>
>> Your question may refer to the "level" tag. In that case your steps are
>> connecting different floor levels of a building. I would not assign a
>> "level" tag value to a stair that connects the first floor (level=1) with
>> the second floor (level=2) of a building.
>>
>> Volker
>>
>> On 2 July 2016 at 12:28, Bjoern Hassler  wrote:
>>
>>> Hi all,
>>>
>>> What is the consensus on the  layer tag for steps?
>>>
>>> In the direction of the way, steps should normally run uphill/upwards,
>>> say from layer=-2 to layer=-1.
>>>
>>> Should the steps be tagged with layer=-2 or layer=-1? Or both (using
>>> different tags)?
>>>
>>> Thanks,
>>> Bjoern
>>>
>>> ___
>>> 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
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New tag

[Andrew Errington]

ref=* would be better, as it's already understood by a lot of other tools
and renderers.

Andrew
On 30 Jun 2016 16:28, "Steve Doerr"  wrote:

> On 30/06/2016 05:27, Hans De Kryger wrote:
>
> How does everyone feel about (store_number=) for store numbers that
> companies assign their stores?
>
>
> Or perhaps branch_number?
>
> --
> Steve
>
>
> --
> [image: Avast logo] 
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com 
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New tag

[Andrew Errington]

Use ref=*

Would that work?

Andrew

On 30 June 2016 at 13:27, Hans De Kryger  wrote:

> How does everyone feel about (store_number=) for store numbers that
> companies assign their stores?
>
>
> *Regards,*
>
> *Hans*
>
> ___
> 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] path=hiking in use

[Andrew Errington]

I disagree.  If we use something specific like footway=hiking then that
implies the path is only for hiking.

It's a path.  Its purpose is for whatever you want to do.  highway=path
perfectly encapsulates the idea "there is a path here".

'hiking' could be used as a tag on a route, which is a set of pieces of
path or road (or steps) which form a hiking trail.

Here in Korea, a lot of the paths are also access for fire wardens and
forestry workers, and on the lower slopes they are used to reach grave
sites for ceremonies and maintenance.

They /can/ be used for hiking, but that is not an exclusive use.

Andrew
On 14 Feb 2016 17:29, "Warin" <61sundow...@gmail.com> wrote:

> On 14/02/2016 6:38 PM, John Willis wrote:
>
>>
>> Javbw
>>
>> On Feb 14, 2016, at 2:09 PM, Andrew Errington <erringt...@gmail.com>
>>> wrote:
>>>
>>> Changing the tags because you don't like the rendering is not the right
>>> approach.  It would be better to lobby for a change of rendering, or use a
>>> different renderer.
>>>
>> Since everything from a sidewalk, a concrete path, a well worn dirt path
>> through the grass around a park, a rough trail through the desert, and a
>> trail up the side of Mt Fuji all have the same vague, meaningless
>> highway=path tag - there is no differentiation possible, so there is no
>> rendering differentiation possible. In any renderer.
>>
>
> OSMAnd is capable of rendering the surface tag! So set your 'hiking path'
> to unpaved (or dirt/sand etc) ... and it can be rendered.
>
> highway=path has always been someone's bandaid.
> I would rebel against path and use footway=hiking!  I would be for the
> removal of highway=path.
>
>
> ___
> 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] path=hiking in use

[Andrew Errington]

Changing the tags because you don't like the rendering is not the right
approach.  It would be better to lobby for a change of rendering, or use a
different renderer.

I use highway=path for my hiking trails, then I make relations to record
the popular, named hiking trails.  Some parts of the trail are
highway=steps, because metal staircases have been installed in some places.

Andrew
On 14 Feb 2016 13:03, "johnw"  wrote:

> I came across path=hiking subkey just now.
>
> I was cleaning up some old tagging, and lamenting the highway=path
> rendering change (now my rural mountain trails are all rendered as
> sidewalks),
> and I was considering changing them all to highway=trail, and then thought
> about a subkey of path, path=trail. But path=* in iD suggested path=hiking.
> I had never seen this before. Taginfo has 2100+ uses of this subkey, though
> it looks like they are all centered somewhere in Europe, with a few random
> ones aound everywhere.
>
>
> If we can get this subkey  documented and approved, and change then ask
> for a rendering change in -carto to something not as infuriating as
> rendering mountain trails like sidewalks, I might be able to live with the
> highway=path tag.
>
>
> Javbw
> ___
> 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] path=hiking in use

[Andrew Errington]

It's a path.  The fact that the line is drawn the same for each type of
path you describe doesn't matter.  The line indicates "a path of some kind
is here".  It should be obvious from the terrain what kind of path should
be expected.

You could add sac_scale, to indicate that this is *not* a simple path:
http://wiki.openstreetmap.org/wiki/Key:sac_scale

Or create a route which incorporates the segments of path you have created:
http://wiki.openstreetmap.org/wiki/Hiking

Andrew
On 14 Feb 2016 16:40, "John Willis" <jo...@mac.com> wrote:

>
>
> Javbw
>
> > On Feb 14, 2016, at 2:09 PM, Andrew Errington <erringt...@gmail.com>
> wrote:
> >
> > Changing the tags because you don't like the rendering is not the right
> approach.  It would be better to lobby for a change of rendering, or use a
> different renderer.
>
> Since everything from a sidewalk, a concrete path, a well worn dirt path
> through the grass around a park, a rough trail through the desert, and a
> trail up the side of Mt Fuji all have the same vague, meaningless
> highway=path tag - there is no differentiation possible, so there is no
> rendering differentiation possible. In any renderer.
>
> The only way to separate sidewalks from hiking trails is to a) abolish or
> severely restrict the usage of the path tag, which people don't want to do,
> b) create Highway=trail key which people don't want to do, so I'd like to
> not have a grossly inferior (and I mean borderline useless) walking map, so
> what is left is to use c) a sub key to get the trails differentiated, so a
> rough hiking path up a mountain or along a riverbed isn't confused with the
> sidewalks and pedestrian walkways that are often nearby or intermingled
> where urban meets rural. I happened upon path=hiking - someone made it
> already.
>
> Not being able to define a rough trail and have it rendered different that
> the other, more urban footways is the same as if all unclassified,
> residential, service, and track were all rendered the same.
>
> Not only do we have all those grades of small roads, we have 5 (!five!)
> grades of track. They (used to?) all get their own rendering too.
>
> Can there be at least 1 trail-ish thing that isn't rendered exactly the
> same as a 1m wide flat concrete path through a park?  We can at least
> document this as "in use" to try to mitigate the conflict caused by path
> and footway used to do the same job in different regions?
>
> Javbw.
> ___
> 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] Named junctions

[Andrew Errington]

Surely this is a rendering problem?

In other words, if there are many named traffic lights within a
certain distance of each other then only one symbol/name/whatever
should be rendered?  If the traffic lights are all tagged the same
then it ought to be even easier.

Adding an area with a tag is just a band-aid, plus it's a lot of work
for mappers.  If we can distil a rule from the data then the computer
can do all the work for us.  Unfortunately, writing software is also
hard, and we have to hope somebody else will do it, but having a clear
explanation of the task is a great help.

It could be something like "when a named traffic light node is found,
add it to a group with that name.  When it's time to label the map,
decide how much space is available for the label, depending on the
zoom level.  At low zoom, draw a single traffic light icon, centred on
the average of the nodes in the group.  At medium zoom, draw a single
icon and a label.  At high zoom, draw an icon for each node, and a
single label in the centre".  This would also work for single named
traffic lights (they are in a group of one).  Single unnamed traffic
lights would work if they are alone (i.e. on a simple junction).
Unnamed traffic lights close together would not work (because they can
not be grouped by name), but there could be a pre-processing step that
makes a group based on the nodes being close together, say within 10m
of each other.

A relation would also be a good solution.  Group the traffic lights
together and add them to a relation with the junction name.  Then
render icons and/or labels for each relation, based on the zoom level.
This would make the rendering code easier, but would be a lot of work
for mappers.

Andrew

On 09/11/2015, tomoya muramoto  wrote:
> Hi Javbw, I want to confirm your point.
>
> *You want to establish a new tag such as traffic_signals_area to solve
> multiple signals rendering.
> *Opinions on the new tag are welcome from Japanese/Asian community because
> rendering of traffic signal and its name is very important for (car)
> navigation in Japan/Asia.
>
> You showed another issue such as dual labels or default map localization,
> but I want to focus on the above issue at this time.
>
> I will post a mail to Japanese ML after some document translation finished
> such as traffic_signals_area.
>
> --
> I like Mapion too. But Mapion is not perfect.
>
> At first, check Yahoo map.
> http://maps.loco.yahoo.co.jp/maps?type=scroll=wgs=map=off=35.4573089010882=139.619295364418=19
> You will see an unnamed traffic signal just north of Tobe (戸部) station.
>
> However Mapion doesn't show it.
> http://www.mapion.co.jp/m2/35.45725737865473,139.61930034601284,19
> And Google map doesn't show it.
>
> And you will notice multiple traffic signals rendering on Mapion just east
> of that signal. Nothing is perfect. But at least we can make OSM better.
>
> muramoto
>
> 2015-11-09 20:28 GMT+09:00 Michał Brzozowski :
>
>> On Mon, Nov 9, 2015 at 11:59 AM, johnw  wrote:
>>
>> > Google Maps is actually two different sets of data: Google’s and a
>> Japanese
>> > GIS company, Zenrin. They have basically surveyed all of Japan building
>> by
>> > building, and everything is drawn area based (because the roads in
>> > Japan
>> can
>> > be such weird shapes and always change width suddenly).
>>
>> Frankly I don't find their road system to be that different to
>> necessitate areal representation, I guess it's more of a tradition
>> thing. But if you don't know, there is area:highway tagging scheme
>> developed by Marek Kleciak that allows to represent roads as areas, as
>> an extension to their linear representation. Note this is distinct
>> from area=yes highways that simply don't have any meaningful axis. If
>> there are resources available, people of Polish community (marimil)
>> could help set up a visualization layer for it.
>>
>> Michał
>>
>> ___
>> 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] Named junctions

[Andrew Errington]

We already use junction=yes for named junctions.  Why is another tag needed?

On 06/11/2015, Gerd Petermann  wrote:
> wow, so the problem is much bigger than I expected.
>
> I still think that my suggestion might help to solve the problem.
>
> My understanding so far:
>
> - In Japan (and maybe other countries),
>
> you would prefer to render only those traffic_signals which have a name
>
> - Complex junctions often require several nodes with
> highway=traffic_signals,
>
> at least for the routing.
>
>
> My suggestion place=junction  could be used for all junctions,
>
> maybe in combination with traffic_signals=yes/no to help the renderer.
>
> A special Japanese style would simply ignore unnamed traffic_signals.
>
>
>  Gerd
>
>
>
> 
> Von: John Willis 
> Gesendet: Donnerstag, 5. November 2015 23:47
> An: Tag discussion, strategy and related tools
> Betreff: Re: [Tagging] Named junctions
>
>
>
>
>
> Javbw
> On Nov 6, 2015, at 1:09 AM, Eugene Alvin Villar
> > wrote:
>
>
> I'd suggest to use a node tagged
>
> place=junction
>
> with name=* or ref=*
>
> for this. What do you think?
>
> From what I remember - in Korea they name junctions, and in Japan they
> actually name the signals themselves.
> I know that sounds like the same thing, but people to speak and refer to the
> Signal at the junction, and the name is on the signal, and the iconography
> used is the signal icon. As there are almost no street names in Japan on
> tertiary roads and below, spatial navigation is done through counting
> *unnamed* signals and occasionally using named signals.
>
> The big problem traffic_signals_area
> was trying to solve is the over-rendering of signal icons.
>
> Billboards, pamphlets, and now websites use static images of maps with
> access directions and simplified maps that show how many signals you have to
> drive through before turning and reaching a destination from a known
> landmark (highway exit, train station).
>
> Here is the access map for a very large park.
>
> http://hitachikaihin.jp/wp-content/uploads/2012/03/996e3788561dbe76ffe45257c28c7c25.png
>
> Note the line of signals in a row. Those are there to be counted.
>
> Because of Japan's very old and extremely convoluted road network, it is
> usually not obvious where to turn - so people not using GPS directions
> (actually using a *map*) Rely **very heavily** on accurate and consistent
> placement of street light icons. And OSM is totally broken in this regard.
> Every node gets an icon. Depending on the zoom level, there is 0-1-2-3-4 or
> more icons when just **one** should be rendered. The signal icon is more
> important that almost all place names.
>
> This is something all the Japanese paper maps and online maps follow, and
> Apple/Google also had to add all the icons properly to be useful *as a map*
> in Japan.
>
> Google Maps of the signals in a row. Note 1 named signal has a name box that
> doesn't cover the road.
>
> https://goo.gl/maps/E1hEzfi3iYF2
>
> OSM has no rendered icons.
> http://www.openstreetmap.org/#map=15/36.3967/140.5927
> It has a label for the lights rendered, but no icons.
>
> Next zoom level - label disappears. So no signals, no labels. Ugh.
> http://www.openstreetmap.org/#map=16/36.4009/140.5901
>
> Now icons - but two of them, with label.
> http://www.openstreetmap.org/#map=17/36.40107/140.58986
>
> Next, 4 icons - no label
> http://www.openstreetmap.org/#map=18/36.40160/140.58949
>
> Finally, at z19, I get 4 icons and a label together.
>
> What a horrible job of rendering a single icon with a single label!
>
> This is an unacceptable situation  for the Map in Japan. It
> fundamentally breaks using the map for road navigation for many many map
> users. and since every other map is better at this fundamental necessity of
> Japanese maps, it basically makes OSM an unusable choice in Japan (for
> spatial map usage while driving) and seem unfinished.
>
> Traffic_signals_area was an attempt to solve this, but as this isn't an
> issue in Europe, it was ignored.
>
> Javbw.
>
>
>
>
> Labeling the signal area is just icing on the cake of removing all the
> unneeded icons cluttering the map.
>

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

Re: [Tagging] Unmarked opening hours

[Andrew Errington]

On 17 Oct 2015 06:00, "Warin" <61sundow...@gmail.com> wrote:
>
> On 17/10/2015 3:58 AM, John Eldredge wrote:
>>
>> I, too, would tend to interpret opening_hours=none as "never open". I
think that opening_hours=unknown would be clearer.
>>
>
> If I don't know something .. I don't tag it.
> So I would simply not add the tag.

This is the right answer.

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

Re: [Tagging] Unmarked opening hours

[Andrew Errington]

On 17 Oct 2015 10:48, "Craig Wallace"  wrote:
>
> On 2015-10-17 01:59, Dave Swarthout wrote:
>>
>>
>> Agreed. Why would you add a tag when you don't know a value to assign? N
>>
>>
>> In addition, concerning the signed:opening_hours=yes/no, there is no
>> need to assign more tags to describe a lack of information about the
>> first one.
>
>
> The point is, it is useful information for surveying.
> eg if I see a shop missing an opening hours tag, I would want to visit
it, to check what the hours are. But if they are not displayed anywhere,
then that survey trip is a waste of my time and effort.
> If I know the hours are not signed, it means I would have to use other
methods, eg ask the staff, or phone them up, or check their website etc. Or
sit there all day, and watch what time it actually opens...
>

So, what you are saying is that a mapper will map the store, but they
couldn't see the opening hours on a sign, so they'll tag
opening_hours=unknown (or whatever).

This allows *you* (or any other mapper) to use other methods to find the
opening hours instead of wasting a journey to the store.

That's great, but couldn't you use those other methods anyway?  And
wouldn't the original mapper think of doing the same thing?  (Personally, I
check the store's website).

Also, from the point of view of a data consumer, how does this help?  If I
am consulting the map it makes no difference if there is no opening_hours
information listed, or if there is a tag saying "I couldn't see a sign".

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

Re: [Tagging] barrier enforcing maxwidth

[Andrew Errington]

So tag a short section of the road before and after the bridge with a
maxwidth tag.  It could differ from the maxwidth of the bridge, but routing
software should determine the minimum maxwidth for any section of a route
(and avoid or penaliseit accordingly).

On 8 September 2015 at 14:59, John Willis <jo...@mac.com> wrote:

> Im talking about how to tag the barrier. That thing was **tight** and very
> unusual to find in a major urban area.
>
> The amount of scars on the poles was amazing.
>
> The hight restriction barrier (a common thing) is tagged along with
> maxheight - this barrier seemed to be the same - if you are over max you
> will hit and severely damage your vehecle on the barrier - not the bridge
> or overpass or whatever.
>
> Javbw
>
> On Sep 8, 2015, at 1:52 PM, Andrew Errington <erringt...@gmail.com> wrote:
>
> I don't think a new tag is warranted.  maxwidth=* is fairly unequivocal.
> If map users or routers want to interpret it as "max width, but probably
> not really, there's probably a bit of extra space, I mean, who's going to
> be that petty" then that's not your problem.
>
> Since most roads do not have a maxwidth=* restriction it is safe to assume
> that the road is suitable for any vehicle*, but if you add a maxwidth tag
> somewhere it is immediately clear it was done purposefully.
>
>
>
> On 8 September 2015 at 12:38, johnw <jo...@mac.com> wrote:
>
>> I was driving in Chiba and Saitama yesterday and encountered a couple new
>> types of barriers. I realized later one is traffic_calming=chicane.
>>
>>
>> The other one is all over rural Japan as traffic_calming=choker on rural
>> roads that could bypass traffic near the rivers, - but this one is not for
>> traffic calming, it is for enforcement of maxwidth of the bridge, similar
>> to barrier=hight_restrictor.
>> . They put very strong steel poles or guardrails along the sides and
>> center of the road at the maxwidth + 20 cm of a standard car.  car can pass
>> (barely, my mirrors were 5 cm away from each pole), but a large dump truck
>> cannot pass. Both are in areas where commercial dump trucks or other large
>> vehicles are nearby, but this one is used to enforce access to the narrow
>> bridge near a very very busy area to keep a massive traffic jam from
>> occurring from a stuck dump truck.
>>
>> https://goo.gl/maps/8KUw7  The maxwidth is signed and guardrails are
>> doing the job. This is width limited for the very narrow bridge in the
>> background.
>>
>> https://goo.gl/maps/3NT9X  The other direction. Poles are used.
>>
>> Is this a reason for creating barrier=width_restrictor ?
>>
>>
>> Javbw
>>
>> ___
>> 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
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] barrier enforcing maxwidth

[Andrew Errington]

I don't think a new tag is warranted.  maxwidth=* is fairly unequivocal.
If map users or routers want to interpret it as "max width, but probably
not really, there's probably a bit of extra space, I mean, who's going to
be that petty" then that's not your problem.

Since most roads do not have a maxwidth=* restriction it is safe to assume
that the road is suitable for any vehicle*, but if you add a maxwidth tag
somewhere it is immediately clear it was done purposefully.



On 8 September 2015 at 12:38, johnw  wrote:

> I was driving in Chiba and Saitama yesterday and encountered a couple new
> types of barriers. I realized later one is traffic_calming=chicane.
>
>
> The other one is all over rural Japan as traffic_calming=choker on rural
> roads that could bypass traffic near the rivers, - but this one is not for
> traffic calming, it is for enforcement of maxwidth of the bridge, similar
> to barrier=hight_restrictor.
> . They put very strong steel poles or guardrails along the sides and
> center of the road at the maxwidth + 20 cm of a standard car.  car can pass
> (barely, my mirrors were 5 cm away from each pole), but a large dump truck
> cannot pass. Both are in areas where commercial dump trucks or other large
> vehicles are nearby, but this one is used to enforce access to the narrow
> bridge near a very very busy area to keep a massive traffic jam from
> occurring from a stuck dump truck.
>
> https://goo.gl/maps/8KUw7  The maxwidth is signed and guardrails are
> doing the job. This is width limited for the very narrow bridge in the
> background.
>
> https://goo.gl/maps/3NT9X  The other direction. Poles are used.
>
> Is this a reason for creating barrier=width_restrictor ?
>
>
> Javbw
>
> ___
> 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] Road classification

[Andrew Errington]

> From this it sounds like this tagging in OSM is relying too much on
> official classification rather than on real road importance.
>
>
I have always maintained that this is the right way to do it.

Official classification is objective and easy to verify.

"real road importance" is purely subjective, open to argument, and
inconsistent.

I think that for any particular country, the official classification
hierarchy should be mapped on to the OSM hierarchy.  If this is not
sufficient for accurate routing then mappers should add more information,
such as lanes=*, maxspeed=*, width=*, traffic lights and so on.  Routers
can 'prefer' highways that are higher up in the hierarchy, and then
penalise sections of the routes that have narrow roads, fewer lanes, or
lower maxspeeds.

Best wishes,

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

Re: [Tagging] waterway=derelict_canal

[Andrew Errington]

On 26/08/2015, Richard ricoz@gmail.com wrote:
 On Wed, Aug 26, 2015 at 03:23:10PM +1000, Warin wrote:
 On 26/08/2015 8:20 AM, Paul Norman wrote:
 On 8/24/2015 3:35 PM, Andy Townsend wrote:
 That's not so bad in lua, but imagine writing ... and not disused=yes
 into every cartocss rule!
 
 Fortunately, we will not have to do that in OpenStreetMap Carto, as we
 will not be supporting the style of tagging where one tag says what
 something is, then another tag saying it's not really that, but used to
 be, or will be. We do not want to encourage the use of disused=yes,
 abandoned=yes, or similar tags.

 Your choice to use what you want.
 The mappers chose to use tags that reflect what is, was or will be. As
 they
 want.

 http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts

Curiously, the disadvantages of disused=yes seem rather contrived,
and not really likely, whereas the disadvantages of disused:*=* seem
quite genuine.  Not to mention that disused=yes is simpler, and very
obvious to a human reader.

Andrew

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

Re: [Tagging] Local highways classifications

[Andrew Errington]

I actually disagree with this criticism.  I think it is appropriate to tag
a road based on its real-life designated classification.  My reason for
saying this is because it is entirely objective.  There have been similar
discussions before which generally conclude with a recommendation to make
what is essentially a subjective decision.

In a previous message I wrote what I considered to be a hierarchy of
highway=* tags.  This would be adequate for simple routers to calculate a
route.  To fix the problem routers need to look at lanes, width, speed
limits etc., and taggers need to tag these more thoroughly.  It could be
that a tertiary or unclassified road *is* better than a primary road
*because* it happens to have more lanes, or is straighter.

Andrew

On Thursday, 16 July 2015, johnw jo...@mac.com wrote:

 Japan has a bad habit of tagging tunnels in remote mountain passes (on
 trunk roads) as motorways because they are toll roads and have no
 pedestrian traffic - but they are just a toll trunk road in a tunnel. it is
 not a motorway.

 They have an even more horrible practice of aligning the unclassified -
 trunk roads by andministrative levels - so a 100 year old national road
 which is windy and single lane is “primary” - but the modern 4 lane bypass
 road built around it 15 years ago is “tertiary” because it is a regional
 road with no shield designation.

 They want to preserve the Japanese method of displaying the routes in the
 Standard Japanese style.

 in Tokyo, it works. In the suburban countryside - it is a routing
 nightmare for western routers - as the road designations do not match their
 usage/purpose in many places.

 Breaking the “admin”  classifications off the roads usage levels would be
 very useful ONLY if there was some additional rendering of the admin
 designation levels on the road (like a different casing color or dashes or
 stronger colors or something) - something visible to go with the OSM road
 level choices so whole countries are not “mapping for the renderer.


 Javbw

  On Jul 16, 2015, at 9:46 PM, Daniel Koć dan...@xn--ko-wla.pl
 javascript:; wrote:
 
  There's a lengthy discussion going on polish forum about using
 motorway/trunk tagging for our main highways:
 
  http://forum.openstreetmap.org/viewtopic.php?id=31488
 
  It looks that whatever solution we will choose, there's no clear mapping
 between OSM and country-level classification of highways, so it makes sense
 to tag them also with well-known and complete local scheme, which could be
 written down like:
 
  highway:class:pl=S/A/GP/G
  highway:category:pl=2/4/6/7 (the number is the same as the corresponding
 admin_level)
 
  I'd like to know if this scheme works also for some other (still
 probably not all) countries, so we could also use:
 
  highway:class:xx=*
  highway:category:xx=*
 
  as a general local-level classification scheme?
 
  --
  The train is always on time / The trick is to be ready to put your bags
 down [A. Cohen]
 
  ___
  Tagging mailing list
  Tagging@openstreetmap.org javascript:;
  https://lists.openstreetmap.org/listinfo/tagging


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

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

Re: [Tagging] service=rural (Was Rural Alley?)

[Andrew Errington]

This is the same in Korea.  Tagging the roads based on their physical
characteristics (such as roadsign type, and with or without centre lines)
is an excellent way to avoid subjective judgements.  Roads that go
somewhere, but have no painted line, are unclassified.  These roads we are
talking about in Japan (and Korea) are not highway=unclassified, and they
are definitely not tracks.

Andrew

On 13 July 2015 at 08:08, John Willis jo...@mac.com wrote:



  On Jul 12, 2015, at 10:34 PM, Martin Koppenhoefer 
 dieterdre...@gmail.com wrote:
 
  Maybe you have to raise your current unclassified roads to tertiary to
 make room for these roads in question?

 Japan tagging rules (on the wiki) states only roads with a painted center
 line can be tagged tertiary. Japan has a more rigid and administrative
 definitions for all roads tertiary and up.

 PS : where are alleys in your statement? They are clearly under
 unclassified.

 Javbw
 ___
 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] service=rural (Was Rural Alley?)

[Andrew Errington]

I think Javbw and I are in agreement, but I don't think a subtag is
required.  Just highway=service (and no service=* tag).

Andrew

On 13 July 2015 at 10:22, Andrew Errington erringt...@gmail.com wrote:

 This is the same in Korea.  Tagging the roads based on their physical
 characteristics (such as roadsign type, and with or without centre lines)
 is an excellent way to avoid subjective judgements.  Roads that go
 somewhere, but have no painted line, are unclassified.  These roads we are
 talking about in Japan (and Korea) are not highway=unclassified, and they
 are definitely not tracks.

 Andrew

 On 13 July 2015 at 08:08, John Willis jo...@mac.com wrote:



  On Jul 12, 2015, at 10:34 PM, Martin Koppenhoefer 
 dieterdre...@gmail.com wrote:
 
  Maybe you have to raise your current unclassified roads to tertiary to
 make room for these roads in question?

 Japan tagging rules (on the wiki) states only roads with a painted center
 line can be tagged tertiary. Japan has a more rigid and administrative
 definitions for all roads tertiary and up.

 PS : where are alleys in your statement? They are clearly under
 unclassified.

 Javbw
 ___
 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] service=rural (Was Rural Alley?)

[Andrew Errington]

I think an additional tag is not necessary.  I think is is sufficient
to tag them with highway=service.  Remember, service=* is simply
clarifying the kind of service road.

They are definitely not tracks.  I remember the discussion about
clarifying track grade 1 and I thought it was stretching a point.

Routers should have a concept of a road hierarchy, and should prefer
higher-classed roads (unless the user specifies otherwise).  The
simplest router could then make a good route by looking only at
highway=*.  Maxspeed, lanes, and other information can refine a route,
and help make a choice between a speed-limited trunk road and a
longer, but unrestricted primary road, for example.

To me, the hierarchy is obvious: motorway, trunk, primary, secondary,
tertiary, unclassified, service, residential, track.  No matter what
grade a track is, it should never be chosen in preference to a service
road, or unclassified.

Andrew

On 12/07/2015, johnw jo...@mac.com wrote:

 On Jul 12, 2015, at 8:07 AM, Warin 61sundow...@gmail.com wrote:

 What you are trying to map is a landuse rather than the highways service?


 Imagine you live on a farm and you’ve never seen a a big city's alley - how
 would you explain why there is a narrow road next to the main road? the main
 road is “too busy?” do they really need to make the road so narrow it is not
 useful for much else than local access?

 In the city and suburban areas, we recognize that there is a road below
 residental/unclassified, but is not a track. We call it an Alley, and define
 it through highway=service  service=alley. Alleys would then connect to
 driveways, tracks, and other more local access roads.

 In my extensive driving experience in rural California, OSM’s definition of
 rural roads works very well. There are no rural alleys. There are service
 roads for individual facilities, but not in the public/narrow/parallel
 “alley” sense.

 But when mapping Rural Japan, IMO, there *is* a road grade between
 unclassified/residential and Track. It is not too difficult to see them when
 you live here, but it is difficult to explain. The guy mapping Korea chimed
 in that it is similar there. The road network in rural ares is *as dense and
 complicated* as the city to facilitate access to farm field sections or
 other rural land-uses. The sections are further subdivided by
 tracks/paths/driveways, like a city. I bet in other very rural, old, and
 high population density countries (in Asia),  this is the case too, if they
 have money to maintain all of these paved roads.

 And using track+grade1 on them seems wrong.

 So I would like to formalize a rural sibling for alley. I called it
 service=rural, becuase it’s counterpart is found in cities and suburbs.


 Javbw

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

Re: [Tagging] Rural Alley?

[Andrew Errington]

Oh, and it's not really an alley, so I wouldn't tag it as such.

A

On 08/07/2015, Andrew Errington erringt...@gmail.com wrote:
 We have something similar in Korea.  I have been using (and
 recommending) highway=service.

 They're not really tracks, as they are proper roads, with a concrete
 or tarmac surface, But, they don't really go anywhere.  I change the
 tags when the road actually becomes a track (two lines of worn dirt
 where the tractor wheels go). I think it's an accurate representation,
 and it renders nicely in most views too.

 Andrew

 On 08/07/2015, Paul Norman penor...@mac.com wrote:
 On 7/8/2015 1:25 AM, johnw wrote:
 [trimmed]
 The issue is that these “small windy roads that go everywhere” go
 nowhere. the land they access is for farming the subdivided sections
 ... lead you on a tour of the local rice plots and hills.

 it is basically access for the farmers, which then have a network of
 (private?) tracks and paths that break the sections down further.

 they just loop around a big rice field, or connect to other roads
 which service other rice fields or logging plots: nothing of interest
 - not even a house - is there. Only the local farmers need use of
 them, but they are public.

 it’s the purpose of the road - the lack of shoulders and other road
 standards, and expected curves, turns, and other “classifications” of
 the road.

  From what you've said about the purpose, it sounds like highway=track.
 The conditions (paved or not, etc) would then dictate the tracktype and
 other tags.



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

Re: [Tagging] Rural Alley?

[Andrew Errington]

I agree, but I based my choice on the description in the wiki.
http://wiki.openstreetmap.org/wiki/Tag:highway%3Dservice

On 08/07/2015, Paul Norman penor...@mac.com wrote:
 On 7/8/2015 2:44 AM, Andrew Errington wrote:
 They're not really tracks, as they are proper roads, with a concrete
 or tarmac surface, But, they don't really go anywhere.
 Tracks can be paved - tracktype=grade1 normally is paved, or is built to
 equivalent quality.

 ___
 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] Rural Alley?

[Andrew Errington]

We have something similar in Korea.  I have been using (and
recommending) highway=service.

They're not really tracks, as they are proper roads, with a concrete
or tarmac surface, But, they don't really go anywhere.  I change the
tags when the road actually becomes a track (two lines of worn dirt
where the tractor wheels go). I think it's an accurate representation,
and it renders nicely in most views too.

Andrew

On 08/07/2015, Paul Norman penor...@mac.com wrote:
 On 7/8/2015 1:25 AM, johnw wrote:
 [trimmed]
 The issue is that these “small windy roads that go everywhere” go
 nowhere. the land they access is for farming the subdivided sections
 ... lead you on a tour of the local rice plots and hills.

 it is basically access for the farmers, which then have a network of
 (private?) tracks and paths that break the sections down further.

 they just loop around a big rice field, or connect to other roads
 which service other rice fields or logging plots: nothing of interest
 - not even a house - is there. Only the local farmers need use of
 them, but they are public.

 it’s the purpose of the road - the lack of shoulders and other road
 standards, and expected curves, turns, and other “classifications” of
 the road.

  From what you've said about the purpose, it sounds like highway=track.
 The conditions (paved or not, etc) would then dictate the tracktype and
 other tags.


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

Re: [Tagging] Rural Alley?

[Andrew Errington]

I looked at that street view.  To me, the way ahead (slightly to the left)
is highway=track.  The roads to the left, right and behind are
highway=service.

A

On 8 July 2015 at 19:27, johnw jo...@mac.com wrote:

 We have something similar in Korea.  I have been using (and
 recommending) highway=service.


 I can get behind that.

 On Jul 8, 2015, at 6:54 PM, Paul Norman penor...@mac.com wrote:

 Tracks can be paved - tracktype=grade1 normally is paved, or is built to
 equivalent quality.


 This is vey confusing to me. I understood it before the big hullabaloo
 over the track classification system change, where track Grade 1 and
 Residential / service / driveway begins now really confusing. Grade 3 roads
 (usually doubletrack with grass growing down the middle) is easy.

 Here, tell me what you think:


 https://www.google.com/maps/@36.431238,139.246753,3a,78y,233.04h,65.44t/data=!3m6!1e1!3m4!1sqk2OIIDRfkCjb8uqWNbkhw!2e0!7i13312!8i6656!6m1!1e1

 here is an intersection where a grade3 track meats a rice service road. in
 the distance, you cans see the unclassified road to the east.

 They go nowhere except back to the unclassified road.  But it is a paved
 and maintained public road with retaining walls and guardrails where there
 is a drain ditch.

 To me, tagging these as track muddies track really badly. they plainly are
 not tracks.

 I have ridden abandoned roads that are now tracks with asphalt, and I have
 driven maintained unclassified and residential roads which are compacted
 gravel.

 what would you suggest Paul?

 Javbw.



 ___
 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] [OSM-talk] OSM is a right mess

[Andrew Errington]

On 05/06/2015, Richard Welty rwe...@averillpark.net wrote:
 On 6/4/15 11:53 AM, AYTOUN RALPH wrote:
 The oneway=yes, oneway=no conundrum.. put yourself in the position
 where you are looking at a road ahead of you. It is only wide enough
 for one vehicle but has passing bays along it's length. It is not wide
 enough to be a conventional twoway road so can it be tagged twoway?
 That would give the impression that cars can progress along it in
 opposite directions at the same timethat would be incorrect. But
 neither direction has the right of way and it is up to driver
 discretion and politeness as to who will reverse back to the passing
 bay. So oneway=no but twoway is not necessary yes.
 i've used

 lanes=1

 and omitted oneway in these cases

I believe this to be the Right Answer.  It's what I do too.

Andrew

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

Re: [Tagging] Comms towers

[Andrew Errington]

According to the wiki:
http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dcommunications_tower

One does.

On 29 May 2015 at 07:18, pmailkeey . pmailk...@googlemail.com wrote:

 What's with

 Man_made=communications_tower
 tower:type=communications

 Does one tag towers with both ?

 --
 Mike.
 @millomweb https://sites.google.com/site/millomweb/index/introduction -
 For all your info on Millom and South Copeland
 via *the area's premier website - *

 *currently unavailable due to ongoing harassment of me, my family,
 property  pets*

 TCs https://sites.google.com/site/pmailkeey/e-mail

 ___
 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] Wiki: Key:level: proposed rewrite

[Andrew Errington]

On 25/05/2015, pmailkeey . pmailk...@googlemail.com wrote:
 The floor level *order* will be clear from the ele(vation) tag, won't it.

No.

Since when has the ele=* tag been used for floors in a building?

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

Re: [Tagging] Wiki: Key:level: proposed rewrite

[Andrew Errington]

Yes, I object.

level=* is an internal value.  Its meaning is absolute, which is
necessary because it is used worldwide.

When the value is displayed, the displaying software should localise the
result according to either the viewer's language, or viewer's location.
Perhaps you are not aware that in some places what British people call
ground floor is called first floor.  However, it is still the same
floor, so it's appropriate to tag it the same (level=0).

The numbers are not meaningless.  They are clearly defined in the wiki.

Best wishes,

Andrew


On Monday, 25 May 2015, pmailkeey . pmailk...@googlemail.com wrote:

 Any objection if I 'rewrite http://wiki.openstreetmap.org/wiki/Key:level ?

 It seems to have been written with the misconception that floor names are
 numbers when they're not.

 A rewrite:

- Won't affect existing names that appear as numbers.
- Will encourage mappers to use correct names for floors (as found in
the building) rather than attempt to convert them to meaningless numbers.


 --
 Mike.
 @millomweb https://sites.google.com/site/millomweb/index/introduction -
 For all your info on Millom and South Copeland
 via *the area's premier website - *

 *currently unavailable due to ongoing harassment of me, my family,
 property  pets*

 TCs https://sites.google.com/site/pmailkeey/e-mail

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

Re: [Tagging] Wiki: Key:level: proposed rewrite

[Andrew Errington]

 It's highly likely that the street level floor would be named 'Ground' - so
 if software needs to know this, that would be a good starting point. It
 could also be worked out by which highway meets the street.

That's funny.  In your previous example no floor is named 'Ground'.

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

Re: [Tagging] surface=brick - surface=bricks?

[Andrew Errington]

On Tuesday, 12 May 2015, Martin Koppenhoefer dieterdre...@gmail.com wrote:


 2015-05-12 7:05 GMT+02:00 Andrew Errington erringt...@gmail.com
 javascript:_e(%7B%7D,'cvml','erringt...@gmail.com');:

 Is there any good reason to avoid changing existing surface=brick to
 surface=bricks?

 Yes.  In English, brick can be an adjective as well as a noun.  As an
 adjective, as it is here, it should have no s.



 why do we use an adjective for bricks when we use nouns for the other
 surface values describing materials, like asphalt, gravel, ground, dirt,
 grass, concrete, paving_stones...?

 Cheers,
 Martin


It's a good question, but most likely it's due to countable and uncountable
nouns.  Bricks are countable, but your other examples (except for paving
stones) are not (therefore they can't be pluralised and we don't add an s).

Having said that, a paving stone surface is correct, but we would
probably say a paved surface.  To use a plural we might say a surface of
paving stones.

Unfortunately, English doesn't restrict itself to rigid grammar rules, so I
can't give you one for this.

Best wishes,

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

Re: [Tagging] surface=brick - surface=bricks?

[Andrew Errington]

Is there any good reason to avoid changing existing surface=brick to
surface=bricks?

Yes.  In English, brick can be an adjective as well as a noun.  As an
adjective, as it is here, it should have no s.

On 12 May 2015 at 05:40, Mateusz Konieczny matkoni...@gmail.com wrote:

 Neither is documented at wiki but meaning seems clear and synonymous.

 surface=bricks is used 1997 times, surface=brick 541 times.

 surface=bricks is also consistent with plural form of popular
 countable surface values - surface=paving_stones and
 surface=concrete:plates

 Is there any good reason to avoid changing existing surface=brick to
 surface=bricks?

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

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

Re: [Tagging] Tagging of pitches within a campsite

[Andrew Errington]

 Hmm, lets experiment ...

 Node
 tourism = camp_site
 camp_site = standard
 name = Happy Jacks

 Node
 tourism = camp_site
 camp_pitch = yes
 ref = 42
 addr:unit = 42
 camp_pitch:picnic_table=yes

 Node
 

 What I don't see here is how to associate the pitches with Happy
 Jacks. I guess the easy solution is to say only map pitches where they
 will fall into an (tourism=camp_site) area ? Hard solution is a
 relation ?

The easy solution is indeed the right answer.  You draw an area to
represent the campsite.  The area has the name of the campsite and its
address and phone number etc.  Inside the area you put nodes for each
pitch.  Tag the pitch with camp_pitch=yes and the reference number for
the pitch in ref=*.

This is what geographical databases are for.  You can infer that the
pitch is in the campsite because the database has tools that let you
do that.  And when you draw the data, humans can see it too.  No
relations needed.

Best wishes,

Andrew

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

Re: [Tagging] Straw pole Temperature=objective default unit?

[Andrew Errington]

There is no regional default if the units are not specified.

In the case of maxspeed it is always km/h if the units are not specified.
If mph is intended then mph must be specified.
http://wiki.openstreetmap.org/wiki/Key:maxspeed

So, for your example of temperature, if the units are not specified then
the value should be interpreted as, say, Celsius.  If a mapper intends the
units to be Fahrenheit then they must include a unit identifier *regardless
of the physical location of the tag*.

-- 
Andrew


On 9 April 2015 at 15:42, Warin 61sundow...@gmail.com wrote:

 Sorry .. I have not made that clear ..

 The default speed limit for motorways on OSM  in, say, Australia would be
 taking regionally, while that for USA would be different and taken for that
 region?

 See http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed ?


 On 9/04/2015 4:16 PM, Lukas Sommer wrote:

 b) values would interpreted by region. Most of the world would be
 Celsius, USA would be Fahrenheit. (Similar to defaults for speed on roads.)

 Please note that speed limits are _not_ interpreted by regions.
 http://wiki.openstreetmap.org/wiki/Key:maxspeed states that the unit
 has to be added explicitly when it’s not km/h – independent of the
 region where you are mapping.

 Region-dependent interpretation of units is IMHO a quite bad idea.

 2015-04-09 5:41 GMT, Bryce Nesbitt bry...@obviously.com:

 How it's entered into the database, and how it's displayed, are two
 separate things.  Humans are messy.  Unless the API starts validating
 entries, entries will vary in format, even if we officially say that 46
 C
 is the official format.  But software can parse and normalize numbers.

 That said: temperature=___ is a problematic tag regardless of the
 formatting of the data.




 ___
 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] Straw pole Temperature=objective default unit?

[Andrew Errington]

On 9 April 2015 at 14:19, Warin 61sundow...@gmail.com wrote:

 To be clear... IF the mapper enters, say,

 temperature=46

 a) this is taken as 46 °C
 b) taken as 46 °C, except in regions where Fahrenheit is use then 46 °F
(similar to default speeds taken as kmh or mph depending on region)
 c) an error and rejected.meet OSM's criteria of verifiable.


I suggest a) it is taken as 46 Celsius.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Straw pole Temperature=objective default unit?

[Andrew Errington]

On 9 April 2015 at 14:00, Jan van Bekkum jan.vanbek...@gmail.com wrote:

 I would prefer a degree symbol. Otherwise you never can be sure that C is
 meant by a mapper from a F region.


Do you mean that, or do you mean a unit symbol?

i.e. do you mean the degree symbol (°) should be present, or do you mean
that C or F should always be present?

Personally I think a degree symbol (°) should not be required, because it's
hard to type, and a C or F should not be required, but if it's missing we
assume C.

You can never be sure that any mapper means something different from what
they recorded.  Either you assume they are correct, or you verify it for
yourself.  I tend to go with the former, otherwise it will drive you mad.

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

Re: [Tagging] Straw pole Temperature=objective default unit?

[Andrew Errington]

I think if no unit is specified then it should be taken to mean Celsius
worldwide.  To define the unit explicitly use n[.n][C|F].  We should also
state that the degree symbol is not required (and maybe that it should
never be present).

At least, that's my opinion.

Andrew

On 9 April 2015 at 10:33, Bryce Nesbitt bry...@obviously.com wrote:

 On Wed, Apr 8, 2015 at 5:52 PM, Warin 61sundow...@gmail.com wrote:

 Please indicate your preference a,b or c. (or d etc if they are
 nominated?)


 Explicit units are better than implicit.

 But there still needs to a be a better defined case for a temperature tag:
 there are very few fixed temperatures that
 meet OSM's criteria of verifiable.

 ___
 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] Fuel shops

[Andrew Errington]

I think they should remain as amenity=fuel (I have visited Thailand and I
know what you mean).  Local people will know what to expect, but for
clarity perhaps subtags should be used to add detail and differentiate
between a filling station and a lemonade stand selling fuel.

On Thursday, 19 March 2015, Lukas Sommer sommer...@gmail.com wrote:

 In Benin (Africa) these shops exist also – mostly only a table with
 some big bottles with fuel.

 2015-03-19 9:18 GMT, Dave Swarthout daveswarth...@gmail.com
 javascript:;:
  I want to float an idea to get your reactions. Here in Thailand, and
  especially in rural areas, there are hundreds of shops that sell motor
 fuel
  in small quantities. Most of the population drive motorbikes which are
 used
  for every sort of transport imaginable. They have a tiny petrol tank,
  perhaps 4-5 liters, therefore a short range; they need frequent fill-ups.
  To meet this need local individuals have set up small sheds or kiosks
 from
  which they hand pump the small quantities needed. Some shops sell fuel by
  the liter bottle, often a whiskey bottle. Such shops are poorly marked,
  seldom have any signs indicating their presence and typically offer no
  other services. If you live in the area you will know where the fuel shop
  is, otherwise they're almost invisible
 
  At any rate, we're looking for a way to tag these fuel shops in such a
 way
  that they become visible in OSM (and on our GPS units), and will not be
  mistaken for a full size fuel service station. Current tagging practice
 is
  to tag them with amenity=fuel and a made up name, for example, Bike
 petrol
  or Drummed fuel. The people doing this are aware of the fact that such
  tagging isn't strictly correct, but they understandably want to be able
 to
  find those shops should they run out of fuel. One problem with this
  Thailand-centric approach, is that other data consumers are unaware of
 it.
  Another is that the informal names are multiplying rapidly and one
 mapper's
  drummed fuel is another's barreled fuel and another's Bike petrol. Where
 it
  will end is anyone's guess.
 
  I'm suggesting an addition to the values of the shop key: shop=fuel or
  perhaps shop=motor_fuel
 
  My goal is to standardize the tagging so that at some point these shops
 can
  be eventually rendered on Garmin compatible downloaded maps and hence
 made
  visible. I have done this for my custom Garmin maps and find it a real
  asset.
 
  Here is a photo of such a shop in my neighborhood:
  https://commons.wikimedia.org/wiki/File%3ABarreled_fuel_shop.jpg
 
  --
  Dave Swarthout
  Homer, Alaska
  Chiang Mai, Thailand
  Travel Blog at http://dswarthout.blogspot.com
 


 --
 Lukas Sommer

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

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

Re: [Tagging] Fuel shops

[Andrew Errington]

But, it *is* a fuel amenity.  It's down to the individual what picture they
have in their mind.  Additional tags would clarify this, but I don't think
alternative tags are needed.

You could set all the fuel types to no (fuel:*=no), or add a new one
(fuel:motorbike=yes).  Or add motorbike=fuel.

Keeping it as amenity=fuel means all mapping tools and search tools
continue to work.

On Thursday, 19 March 2015, Jan van Bekkum jan.vanbek...@gmail.com wrote:

 I would prefer a different tag as I would not like the lemonade table to
 be rendered in the same way as a regular filling station. The tag shop=gas
 with subtag would be better.

 On Thu, Mar 19, 2015 at 11:46 AM Andrew Errington erringt...@gmail.com
 javascript:_e(%7B%7D,'cvml','erringt...@gmail.com'); wrote:

 I think they should remain as amenity=fuel (I have visited Thailand and I
 know what you mean).  Local people will know what to expect, but for
 clarity perhaps subtags should be used to add detail and differentiate
 between a filling station and a lemonade stand selling fuel.

 On Thursday, 19 March 2015, Lukas Sommer sommer...@gmail.com
 javascript:_e(%7B%7D,'cvml','sommer...@gmail.com'); wrote:

 In Benin (Africa) these shops exist also – mostly only a table with
 some big bottles with fuel.

 2015-03-19 9:18 GMT, Dave Swarthout daveswarth...@gmail.com:
  I want to float an idea to get your reactions. Here in Thailand, and
  especially in rural areas, there are hundreds of shops that sell motor
 fuel
  in small quantities. Most of the population drive motorbikes which are
 used
  for every sort of transport imaginable. They have a tiny petrol tank,
  perhaps 4-5 liters, therefore a short range; they need frequent
 fill-ups.
  To meet this need local individuals have set up small sheds or kiosks
 from
  which they hand pump the small quantities needed. Some shops sell fuel
 by
  the liter bottle, often a whiskey bottle. Such shops are poorly marked,
  seldom have any signs indicating their presence and typically offer no
  other services. If you live in the area you will know where the fuel
 shop
  is, otherwise they're almost invisible
 
  At any rate, we're looking for a way to tag these fuel shops in such a
 way
  that they become visible in OSM (and on our GPS units), and will not be
  mistaken for a full size fuel service station. Current tagging
 practice is
  to tag them with amenity=fuel and a made up name, for example, Bike
 petrol
  or Drummed fuel. The people doing this are aware of the fact that such
  tagging isn't strictly correct, but they understandably want to be
 able to
  find those shops should they run out of fuel. One problem with this
  Thailand-centric approach, is that other data consumers are unaware of
 it.
  Another is that the informal names are multiplying rapidly and one
 mapper's
  drummed fuel is another's barreled fuel and another's Bike petrol.
 Where it
  will end is anyone's guess.
 
  I'm suggesting an addition to the values of the shop key: shop=fuel or
  perhaps shop=motor_fuel
 
  My goal is to standardize the tagging so that at some point these
 shops can
  be eventually rendered on Garmin compatible downloaded maps and hence
 made
  visible. I have done this for my custom Garmin maps and find it a real
  asset.
 
  Here is a photo of such a shop in my neighborhood:
  https://commons.wikimedia.org/wiki/File%3ABarreled_fuel_shop.jpg
 
  --
  Dave Swarthout
  Homer, Alaska
  Chiang Mai, Thailand
  Travel Blog at http://dswarthout.blogspot.com
 


 --
 Lukas Sommer

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

 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 javascript:_e(%7B%7D,'cvml','Tagging@openstreetmap.org');
 https://lists.openstreetmap.org/listinfo/tagging


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

Re: [Tagging] Spelling: vending=news_papers

[Andrew Errington]

On Sun, 22 Jun 2014 22:22:46 Andreas Goss wrote:
 I was fixing some stuff with http://keepright.at/ when I found an error
 showing a wrong spelling vending=newspapers and the right tag was
 vending=news_papers. Which confused me, because I was pretty sure that's
 the spelling I learned in English class and google also confirmed that.
 Checking with taginfo and the German wiki that's actually what it states
 and what is used, the spelling was only corrected in the English Wiki.
 (Most of the nodes are in Germany)
 
 So what now? News papers just seems completely wrong. I guess a mass
 edit is not really possible in OSM.

You are right.  The correct word is newspapers.  keepright is wrong and 
ought to be fixed.

Best wishes,

Andrew

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

Re: [Tagging] Structure on the end of tunnel to cover sun and avoid bright blindness

[Andrew Errington]

On Wed, 14 May 2014 18:33:43 Martin Koppenhoefer wrote:
 2014-05-14 7:17 GMT+02:00 Andrew Errington erringt...@gmail.com:
  You could also refer to the Wiki:
  http://wiki.openstreetmap.org/wiki/Key:tunnel
  
  For covered passages which are open on one side, often found on mountain
  roads or ways underneath a building, use covered=* in place of tunnel=*.
  
  Or tunnel=avalanche_protector
 
 but these are quite distinct from what he wants to map, these look like
 this:
 http://static.panoramio.com/photos/large/65229337.jpg
 http://media3.news.ch/news/680/313512-4de97c69c4cee4603fb8c37a905af6c3.jpg
 
 cheers,
 Martin

Looks like covered=* to me.

Andrew

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

Re: [Tagging] Structure on the end of tunnel to cover sun and avoid bright blindness

[Andrew Errington]

On Wed, 14 May 2014 05:13:20 Martin Koppenhoefer wrote:
  Am 13/mag/2014 um 20:30 schrieb Nelson A. de Oliveira
  nao...@gmail.com:
  
  building=shade seems better
 
 this could be a idea if you map the structure itself, or maybe
 building=shading_structure
 
 you can also split the highway and add an attribute like shaded=yes
 or shading_structure=yes or covered=shade
 
 cheers,
 Martin
 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging

You could also refer to the Wiki:
http://wiki.openstreetmap.org/wiki/Key:tunnel

For covered passages which are open on one side, often found on mountain 
roads or ways underneath a building, use covered=* in place of tunnel=*.

Or tunnel=avalanche_protector

Best wishes,

Andrew

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

Re: [Tagging] layer=-1, rivers, bridges and tunnels

[Andrew Errington]

On Tue, 22 Apr 2014 17:58:35 André Pirard wrote:
 The Osmand's (or its renderer's) bug looks much like this.
 To say it more precisely than it looks bad, It uses dotted lines for
 -1, -2 and probably below. There is no reason why.
 It should be corrected and not be worked around by changing all levels
 all over OSM (and discovering that doing so raises another bug in Osmxor).

I don't understand.  You say that we should correct the bug in Osmand, and 
changing the layers is working around the bug.  Even if Osmand is fixed, 
tagging layer=-1 on a river is wrong.

The thing that must be corrected is the incorrect use of layer tags!  If this 
raises errors in Osmxor, which I have never heard of, by the way, then Osmxor 
should be changed, perhaps to a warning, not an error (or bug, or whatever it 
does).

Best wishes,

Andrew

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

Re: [Tagging] layer=-1, rivers, bridges and tunnels

[Andrew Errington]

Mea culpa, except that the layer=* tag is a hint for the renderer.

Should I add layer=-1 to all the rivers and streams again?

If not, why not?

Best wishes,

Andrew

PS I didn't want to mention the lake that was tagged layer=-2, but I
fixed that too.  Having visited it I can confirm it is indeed on top
of the dirt underneath it.

On 21/04/2014, Pieren pier...@gmail.com wrote:
 On Sat, Apr 19, 2014 at 1:46 AM, Andrew Errington erringt...@gmail.com
 wrote:

 I am using OSMAND for navigation, so it's important to have clear maps.
 Now
 that I have downloaded the latest data for this area (which includes my
 updates) I am much happier with the map I see.

 Without any additional tags like tunnel=* or covered=*, a
 layer=-1 river shouldn't be rendered differently than a layer=1 or
 even in the absence of any layer tag. This is a bug in OsmAnd. You
 clearly admit that you tag for the renderer.

 Pieren

 ___
 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] layer=-1, rivers, bridges and tunnels

[Andrew Errington]

As I said earlier, I fixed a lot of rivers and waterways nearby that were 
incorrectly tagged as layer=-1.  I removed the layer tag (since it is not 
necessary on a river or stream) and checked all the bridges and tunnels in the 
area.  Some bridges and tunnels did not have a layer tag, which is an error, 
so I added them correctly.

The main reason for doing this (other than to correct poor mapping) is because 
OSMAND draws rivers with 'layer=-1' differently to rivers with no layer tag, 
and it looks bad, especially where there *are* sections of river correctly 
tagged with layer=-1, such as in a tunnel, for example.

I am using OSMAND for navigation, so it's important to have clear maps.  Now 
that I have downloaded the latest data for this area (which includes my 
updates) I am much happier with the map I see.

Best wishes,

Andrew

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

Re: [Tagging] layer=-1, rivers, bridges and tunnels

[Andrew Errington]

I have discovered a bunch of rivers and streams with layer=-1 in my
local area.  In my opinion this is simply wrong, so I am removing the
layer tag from the river and checking for objects which cross the
river (to tag them with layer=1.

Best wishes,

Andrew

On 02/04/2014, Bryce Nesbitt bry...@obviously.com wrote:
 The present situation is that rivers implicitly render below highways in
 all common renderings.  That's not necessarily bad. With some formality to
 the layering arrangement, it sure would save a lot of tagging hassle and
 maintenance.

 The new cloud tag for example, is clearly to be rendered after everything
 but the celestial tags.

 Ahem.
 April 1st aside: the number of important implicit assumptions is relatively
 small.  Rivers under, power lines over, closed ways under except if they're
 tagged building, etc.  Currently this type of layering is implicit in
 various bits rendering software, but
 it could be formalized at the tag definition level to help meet certain
 mapper expectations.

 ---
 In the case of the river/highway layer warning: if the warning had never
 existed, chances are the various workaround schemes would never have come
 up.  Rivers would run under roadways, and tagging would be needed only in
 the rare case of a ford or an arroyo with no culvert.


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

Re: [Tagging] Study area

[Andrew Errington]

We have them here in Korea.  Students pay per month and use the room
to study in.  The main reason they exist is because of the dense
housing here it's sometimes hard for students to get a quiet place to
study.

The ones I am talking about are not really co-working space.  They are
for middle- and high-school students.  They are called study rooms.

Best wishes,

Andrew

On 27/02/2014, Dave Swarthout daveswarth...@gmail.com wrote:
 @Stephan: I like the coworking_space idea. It certainly fits the practice
 at Punspace.

IMO if we have the opportunity we shouldn't use amenity key.

 @Stefano: Why do you think we should not use the amenity key?


 On Thu, Feb 27, 2014 at 2:50 PM, sabas88 saba...@gmail.com wrote:




 2014-02-27 8:45 GMT+01:00 Stephan Knauss o...@stephans-server.de:

 On 27.02.2014 01:48, Dave Swarthout wrote:

 @Martin, I'm not sure about the status of the books but that's not the
 prominent feature of this place. I will go back for more details later
 but it is definitely not a library.
 @Stephan - neither Punspace or Guru's Box are tagged. I brought that
 fact up during the meeting we had there and nobody had any ideas.
 Punspace is similar to the place I'm reporting here except it is not
 free and available for short term rental only.


 a while ago it was suggested to use office=coworking for coworking
 places. with fee=yes/no you could also distinguish the free and paid
 ones.

 In the co-working thread is sounded like office is the better key and
 should be preferred over amenity. Still in February a wiki page for the
 amenity key was created.

 http://wiki.openstreetmap.org/wiki/Tag%3Aamenity%3Dcoworking_space


 Well, it wasn't approved so it should be moved to Proposed_Features
 space..
 IMO if we have the opportunity we shouldn't use amenity key.


 https://lists.openstreetmap.org/pipermail/tagging/2013-
 November/015668.html

 Taginfo:
 Count   Key Value
 48  amenity coworking_space
 15  office  coworking
 6   office  coworking_space
 2   amenity coworking_place


 Stephan


 Regards,
 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




 --
 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] Feature Proposal - RFC - drinkable

[Andrew Errington]

Ah, the wheel has turned full circle.  We had this same discussion a
couple of years ago.

IMHO potable is the right answer, but amazingly, although everyone
who joined the discussion knew what it meant, they all thought it
shouldn't be used in case someone didn't know.

Best wishes,

Andrew

On 27/02/2014, Dave Swarthout daveswarth...@gmail.com wrote:
 I think the term drinkable might be more attractive because it is so
 closely related to the term drinking_water —  it's a logical extension of
 the top level amenity tag:
 amenity=drinking_water (drinkability=yes assumed)
 to different water sources such as fountains, springs and water wells.

 Potable is an English word derived from Latin and its meaning is perhaps
 not obvious to non-native English speakers whereas drinkable doesn't suffer
 as much from that limitation.

 Regards,
 Dave



 On Thu, Feb 27, 2014 at 2:34 PM, Bryce Nesbitt bry...@obviously.com
 wrote:

 potable seems a less ambiguous term.
 https://wiki.openstreetmap.org/wiki/Key:drinking_water has tagging
 momentum.

 ___
 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] Topographic place names

[Andrew Errington]

On Tue, 10 Dec 2013 19:26:55 Steve Bennett wrote:
 Hi all,
   My cycletouring map, http://cycletour.org, has been slowly morphing into
 a general topographic map[1]. One thing that's missing, though, is names
 for topographic features like mountain ranges, spurs, and general areas.

 Looking at http://wiki.openstreetmap.org/wiki/Category:En:Key:natural,
 there seem to be some gaps.

 - how do you tag a mountain range? That is, not a single ridge or mountain,
 but a line of mountains, potentially hundreds or even thousands of
 kilometres long
 - how do you tag a spur? In Australia, many spurs are named, (Champion
 spur, Son of a bitch spur). natural=ridge perhaps?
 - how do you name a generic geographic feature, like a cluster of rocks
 (Mushroom rocks) or a vague features like the blowhole, something
 hollow. The tags are all very specific and seem to imply the ability to
 render it somehow other than using words. (I have ended up using
 place=locality for some of these but it doesn't seem right.)

 Steve
 [1] See this area for instance: http://bit.ly/1gVmycD


Yes please!  I just added some hiking trails and had a named spur[1] that I 
wanted to record.  I used place=locality, but it seems wrong for the same 
reasons you give.  I'd suggest that since we have natural=peak, and 
natural=saddle we should have natural=spur.  natural=ridge, if it's not 
already used, should be for ridges.  Perhaps we could also have 
natural=feature for a general named 'thing' that is visible and well known.  
Could be any sort of rock, outcrop, fissure etc.

A

[1] http://www.openstreetmap.org/#map=15/35.7236/128.0624layers=C

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

Re: [Tagging] Security Gate Post/Cabin

[Andrew Errington]

On 9 December 2013 15:55, Paul Johnson ba...@ursamundi.org wrote:
 Pinkertons call this a Police Box, at least in the pacific northwestern US,
 and even prior to the recent Doctor Who fad.

Recent?

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

Re: [Tagging] tourism=guest_house or tourism=bed_and_breakfast ?

[Andrew Errington]

On Fri, 18 Oct 2013 01:47:51 Dudley Ibbett wrote:
 From a tourists perspective it is quite important to know whether it is
 self catering accommodation or not.  It is also important to know whether
 it is a single building unit (i.e. house,cottage,chalet) as opposed to a
 number of units in a building (i.e. apartments).  I would be inclined to
 use tourism=apartments for the latter.  Types of tourist accommodation do
 seem to be quite country specific.  There are very few tourist apartments
 in the UK but they are very common in Croatia for example. I would agree
 that tourism=chalet would seem to be the most appropriate tag for a gîte.

Surely it's simply a matter of tagging There is accommodation of some kind 
here and including a URL to the website?  There is very little point in 
slicing the data so thinly, especially since renderers will paint a little 
picture that probably looks identical for any class of tourist accommodation.

With a website URL, the OSM map user can hop over to the hotel's site and read 
all about the number of rooms and facilities.

What I really think would be nice is to specify an osm.xml file that a 
business can put on its website.  Inside OSM we would tag the place with a 
URL for that file, and we copy a small set of basic tags taken from that 
file, sufficient to render the object.  Periodically we can automatically (or 
semi-automatically) refresh the tags with the content of the file. (If there 
is no file, or no URL we just tag manually as we do now).  Then at runtime, 
whenever someone seems interested in the place the mapping app uses the URL 
to fetch the contents of the XML to display to the user.  The advantage of 
this is that it distributes the data, and allows the site owner to maintain 
the details without filling OSM up with useless cruft.  The XML file could 
even be dynamic and contain current vacancies, prices, upcoming closures (for 
renovation) etc.

Best wishes,

Andrew

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

Re: [Tagging] Call for more feedbacks about emergency=aed or emergency=defibrillator

[Andrew Errington]

On Wed, 09 Oct 2013 18:06:52 Pieren wrote:
 On Wed, Oct 9, 2013 at 12:06 AM, Bryce Nesbitt bry...@obviously.com wrote:
  On the units I've seen in the wild the term aed or AED appears in
  nearly every case, but the word defibrillator is frequently absent.

 On Wed, Oct 9, 2013 at 2:32 AM, Andrew Errington

  Yup, in Japan they are *everywhere*, with orange enclosures and big
  letters reading AED.

 From what I've seen in different pictures is that the label AED is
 never alone and you can read the word defibrillator translated into
 the local language for obvious reasons. I'm happy to see that in some
 countries, everybody knows what AED means... just think about the
 other countries.

I was.  What are you going to call an AED in any language?  If you have 
an A, an E, and a D sound in your language, that's what it will be 
(unless you're French, DAE, or Spanish, DEA).  Besides, putting 'aed' in 
a tag does not mean that 'aed' should appear when it's rendered.  Only the 
definition is important, and English is commonly used in OSM for that.  Once 
someone has tagged something as 'aed' (since that is what it *is*), you can 
render it any way you like.

Here are some examples from Japan:
http://nottotallyrad.blogspot.kr/2008/10/aed-lessons-from-japan.html

How shall we tag a vending machine with an AED storage compartment?

Andrew

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

Re: [Tagging] Call for more feedbacks about emergency=aed or emergency=defibrillator

[Andrew Errington]

On Wed, 09 Oct 2013 07:06:54 Bryce Nesbitt wrote:
 On the units I've seen in the wild the term aed or AED appears in
 nearly every case, but the word defibrillator is frequently absent.


Yup, in Japan they are *everywhere*, with orange enclosures and big letters 
reading AED.

Andrew

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

Re: [Tagging] Ace Hardware

[Andrew Errington]

Either they are associated with Ace Hardware, or they are not.  If they
are, then it's probably easiest to use brand=*.  I doubt very much that
they are a co-op.

My suggestion:
brand=Ace Hardware
name=(the store name)
operator=(the name of the owner)

Best wishes,

Andrew


On 30 August 2013 11:55, Serge Wroclawski emac...@gmail.com wrote:

 In the United States and Canada, we have a very large organization of
 hardware stores called Ace Hardware:
 https://en.wikipedia.org/wiki/Ace_Hardware

 Each Ace Hardware is independently owned and operated, and each of
 them uses their own name.

 But they all belong to a single organization called Ace Hardware,
 which provides them benefits in ordering, etc.

 Since each store is independently owned and operated, the operator
 tag does not fit, since the stores are not controlled by a central
 organization, such as would be the case with a franchise.

 And since each store is branded uniquely, and don't always use the
 name Ace Hardware in their name[1] or other material, I don't think
 brand fits either.

 But we may want to indicate that the relationship between store and
 co-op exists, so in this case, since they belong to a co-op, I've used
 co-op=Ace Hardware.

 If someone has an alternative suggestion for this type of arrangement,
 I'm interested in hearing it.

 - Serge

 [1] Sometimes they do, such as in the case of Springfield Ace
 Hardware (a real place), but two Ace Hardware stores near me are
 called Aquarius Hardware and AJO Home and Lumber, neither of which
 indicates any affiliation.

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

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

Re: [Tagging] Hiking tracks as POIs in Brazil

[Andrew Errington]

I agree.  I have mapped some hiking trails in Korea and noticed there
is nothing specific to mark the start of a trail.

I suppose it could be done programmatically.  It is clear which node
is the first one, so it could be rendered differently, with extra
detail extracted from the tags on the  track itself.  However,
explicit is better than implicit, so I'd like to see something for
this.

Best wishes,

Andrew

On 09/08/2013, Bryce Nesbitt bry...@obviously.com wrote:
 On Thu, Aug 8, 2013 at 10:34 PM, Volker Schmidt vosc...@gmail.com wrote:

 What you are looking for is a tagging for trailhead I suppose.
 Are these trails signed (trailblazed)?
 I notice that the National Park OSM initiative does not propose an OSM
 tag
 for their trailhead sign (see:
 https://wiki.openstreetmap.org/wiki/US_National_Park_Service_Tagging)
 I personally would be in favour of creating a formal tag for trailheads
 (I
 had pondered this in the past on occasion,but never taken action).

 +1 on this.
 Trailhead is a glaring omission to date.  Trailhead is a common map symbol
 on printed maps, trailheads often have names, and are
 natural rendezvous points for humans.  In OSM one can sort of cobble a
 trailhead together from parking and information= tags, but it is not quite
 right.


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

Re: [Tagging] Tagging camp sites within campground

[Andrew Errington]

On Mon, 17 Jun 2013 22:19:48 Tod Fitch wrote:
 In the case I am looking at now there is no street number for the
 campground. At least there is no sign indicating one nor have I seen a
 street number on an any map. So I guess that addr:housenumber might work.
 But I imagine that there are campgrounds that actually have an street
 number assigned to the whole complex, so overloading addr:housenumber would
 not work.

 For what it is worth, the practice in the area I an interested in for
 dispatching emergency services is to use the campground name and then the
 written reports, if for Forest Service, use the old township and range
 location. Other agencies might be using UTM grid nowadays.

 addr:unit seems like a reasonable choice for tagging the individual
 campsite. In the case where the whole campground has an street address, it
 seems like adding a unit number to the campground address is sufficient.
 But the Forest Service campgrounds in many of the areas I visit have no
 obvious street address and the service roads within the campground are
 usually unnamed too. So what, if anything, should be used for the
 addr:street tag?

 Any objections to using a addr:housename tag set to the campground name?
 Seems like that fits Bryce's old mailman analogy as an address that might
 have been deliverable.

Yes.  Instead, I suggest that you use tourism=camp_site and put the name in 
name=*
http://wiki.openstreetmap.org/wiki/Tag:tourism%3Dcamp_site

I would also suggest that addr:*=* is inappropriate for pitches on the site.  
addr:*=* would be for the campsite itself, probably the site office, but if 
there is no address (for the campsite) then you can't make one- just use 
name=* as above.

How about making a set of tags for a pitch?  (pitch is the area upon which 
the caravan or tent is situated).  You can create a node or an area (probably 
a rectangle) and use ref=* for the pitch number.  I don't know quite how to 
do the namespace, but something like:
camp_site=pitch (this is a pitch for a tent or caravan or motorhome)
camp_site:parking=yes/no (you can park next to your tent)
camp_site:electric=yes/no (there is an electrical hookup for this pitch)
camp_site:water=yes/no (there is a water tap for this pitch)
camp_site:drain=yes/no (there is a grey water drain for this pitch)
camp_site:type=tent;caravan;motorhome/static (the things we can put on this 
pitch)
camp_site:surface=grass/gravel/concrete

Best wishes,

Andrew

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

Re: [Tagging] pastry and confectionery

[Andrew Errington]

Why not record the URL of the store in website=*?  That way people can
visit the store's website and see for themselves what they sell.

The benefit of this is that if the shop alters their range of goods
you don't need to alter the tags.  The store will update their
website.  So, all you need is a top-level generic tag (shop=bakery,
meaning general baked goods store).

Personally, I think generic tags are perfectly sufficient.  If I visit
an unfamiliar town, and I am looking for a certain item, such as
artisanal bread baked by unicorns, I am quite happy to see a list of
half a dozen potential places in OSM (maybe all tagged shop=bakery)
and then explore them myself to find out which one is best for what I
want.  Furthermore, when I am tagging I don't want to agonise over
which of 100 tags is appropriate.  This is the key to map making-
knowing what to omit.

Best wishes,

Andrew

On 7 June 2013 14:42, Johan Jönsson joha...@goteborg.cc wrote:
Michael Krämer ohrosm@... writes:
 ..snip..
 Basically I think we're on the same page: To my understanding we agree
 that there's a need to differentiate between the different kinds of
 baked goods. So the problem is how to classify and name these.
 But as pretty often I guess that's where trouble starts.
 ..snip..

 Murry McEntire murry.mcentire@... writes:

 ..snip..

 1) Pastries should definitely not be listed as a product of
 shop=confectionery.2) A more correct definition for shop=bakery is selling
 cakes, pastries, pies and bread

  -- or tongue in cheek: selling cakes, pastries, pies and sometimes
 bread, but rarely bread alone

 ..snip..

 Murry

 It looks too me that both american Murry and german Michael have found that
 a breadselling shop is different from a pastry-selling shop. So why not do
 as the Original Poster, Martin, wrote and distinguish these two.

 (The discussed problem seem to be that bread-shop is bäckerei in german and
 that pastry-shop is bakery in english, similar name for different things)

 We might even need to go so far to consider to abandon shop=bakery and use
 shop=bread and shop=pastry instead.

 p.s.
 Shop=bakery and shop=butcher where the first shop-values, when the shop-key
 broke out from amenity-key. These two really are old entities that have been
 with us in our culture for a long time and kind of demands to be tagged.
 d.s.



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

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

Re: [Tagging] pastry and confectionery

[Andrew Errington]

On Fri, 07 Jun 2013 17:42:32 Martin Koppenhoefer wrote:
 2013/6/7 Andrew Errington erringt...@gmail.com

  Why not record the URL of the store in website=*?  That way people can
  visit the store's website and see for themselves what they sell.

 of course you do this IF they have a website (traditional smaller ones
 usually won't have a website I guess, not even in 2013), but this isn't an
 alternative to setting a class. If you wanted to see how many bakeries
 (that sell bread, not exclusively cakes) are in Germany, with your system
 you needed months to check ;-)

I only need to check the ones that are within 500m of my hotel.  :)

 Thought your argument to the extreme, you would only tag website=* and
 poi=yes ;-)

You know, I've been thinking that might be a possibility.  Allow a website 
owner to hold his or her own tags.  The tags could be held in a file on the 
website in much the same way as robots.txt or an RSS feed, or a vcard file, 
and the store/facility/whetever has an object (node or area) in OSM with the 
URL.  A program periodically extracts objects from the OSM database and 
fetches the tags from the store's website.  Tags are added, modified or 
deleted appropriately.

I suppose we could do something similar to this now, if the store's URL is in 
the OSM database we could try to extract things like phone number and address 
by querying the webpage, after all, it's all machine readable.  If we can't 
trust it to be completely automatic the results could be passed to a human 
for verification.

While I am on this flight of fancy, how about Update POI by email?  Send an 
email to an OSM address containing the object ID and a list of tags.  A 
program at OSM receives the email, checks the sender's ID against the 
database of OSM users, and updates the tags based on the contents of the 
email.  If the message can not be parsed or it contains any errors then it is 
all discarded and the sender notified.

Best wishes,

Andrew

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

Re: [Tagging] Tagging 'averaged' paths in rural Mali

[Andrew Errington]

On Mon, 11 Feb 2013 19:31:06 Pieren wrote:
 On Mon, Feb 11, 2013 at 2:08 AM, Andrew Errington erringt...@gmail.com 
wrote:
  How about drawing a single 'representative' way as you have been doing,
  and adding width=100?

 ?? and why not 500...

Because the OP stated the extent of the parallel ways to be about 100m.

Best wishes,

Andrew

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

Re: [Tagging] Tagging 'averaged' paths in rural Mali

[Andrew Errington]

On Mon, 11 Feb 2013 20:05:37 Pieren wrote:
 On Mon, Feb 11, 2013 at 11:55 AM, Martin Koppenhoefer

 dieterdre...@gmail.com wrote:
  +1 to not add width=100 to one single generalized way, that would mean
  something very different.

 -1
 Saying this road is 100m wide is a joke when you are in the middle of
 the desert and try to simply follow the previous marks in the sand...

You can easily see 100m.  The line on the map represents a route, it is not 
the route itself.  By setting the width to 100m you allow for a person to 
travel anywhere within a 100m wide path and still reach the destination.

OP asked for practical solutions.  Drawing a dozen or so meandering paths from 
point A to point B is not practical.

Best wishes,

Andrew

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

Re: [Tagging] Tagging 'averaged' paths in rural Mali

[Andrew Errington]

On Mon, 11 Feb 2013 01:46:43 william skora wrote:
 Hey everyone,

 As you may know, HOT is currently mapping infrastructure in Mali. In flat
 rual areas, there are
 some 'highways' (unpaved ground) that are very close to each other (up to
 ~100 meters ) that all lead to the same villages or destinations.
snip
 Do you have any suggestions of how to tag these ways ?

 Regards,
 will

How about drawing a single 'representative' way as you have been doing, and 
adding width=100?

Best wishes,

Andrew

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

Re: [Tagging] Is the difference between power station and sub station clear?

[Andrew Errington]

On Thu, 24 Jan 2013 18:40:05 François Lacombe wrote:
 Ok, I agree with you about substation vs sub_station.


 Consensus seems to emerge from this discussion, I would edit the wiki like
 polderrunner explained.

 * Deprecation (not removal) of power=station, power=substation (and all
 other values), message adding at the top of keys' pages. power=sub_station
 will be the only valid value. It will encourage mappers to migrate existant
 power=station to power=sub_station.


As a native English speaker, I have to tell you that 'substation' is the 
correct word.  Please do not use 'sub_station'.

Best wishes,

Andrew

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

Re: [Tagging] Follow-up on Time Domains

[Andrew Errington]

On Tue, 22 Jan 2013 06:36:57 Serge Wroclawski wrote:
  there have been some minor additions resulting in an updated spec.

 The one comment I have is that I'm not at all used to seeing two
 letter days of the week.

 I've always seen them as Mon, Tue, Wed, Thur, Fri, Sat, Sun.

 This is obviously cultural, but we want these to be as natural as
 possible.

Surely this is 'internal'.  That is, it's nice that some people can read Mo, 
Tu, We, etc., but for others, they are just 'coded' days of the week.  Date 
producers need to understand the meaning of Mo, Tu, etc. so that they can 
record them properly in the database, but data consumers need to translate 
these to something that can be displayed nicely.

For example, you may like to see Mon, Tue, Wed, etc., so for your renderer 
there should be a mapping table Mo-Mon Tu-Tue and so on.  For a Korean 
renderer there should be a table Mo-월 Tu-화 We-수, etc.

I think the *definition* for recording the opening times in the database 
should specify two-letter English abbreviations for days (and three-letter 
English abbreviations for months) and leave it to localised software to 
translate them appropriately.

Best wishes,

Andrew

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

Re: [Tagging] Proposed feature - age groups in schools

[Andrew Errington]

 2012/11/26 Philip Barnes p...@trigpoint.me.uk:
  In the UK public schools are expensive fee paying private schools, such
  as Eaton, Harrow etc.

 thanks for clarification, for those interested in further info:

 http://en.wikipedia.org/wiki/Public_school_(United_Kingdom)


 The state_school article (
 http://en.wikipedia.org/wiki/Public_school_(United_Kingdom ) has another
 synonym: government school, maybe we could use this?

I think 'state school' is more common.  I don't think any English speaker 
would say 'government school'.

Best wishes,

Andrew

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

Re: [Tagging] Tag ref on motorway_link

[Andrew Errington]

On Wed, Oct 24, 2012 at 2:10 PM, David ``Smith'' vidthe...@gmail.com wrote:

 On Oct 24, 2012 12:25 AM, Andrew Errington erringt...@gmail.com wrote:

 On Wed, Oct 24, 2012 at 10:31 AM, Richard Welty rwe...@averillpark.net
 wrote:
  this is why i don't put New York State Reference Route numbers in the
  ref tag, i put them in ref:unsigned which isn't rendered.

 Isn't that simply tagging for the renderer?  And doesn't this just mean

 I put them in ref:unsigned which isn't rendered...

 ...yet.

 or

 ...by this particular renderer.

 Who would make a renderer that renders the value of a key like
 ref:unsigned?

Probably no-one, because it's not documented.

  A roadgeek probably, but I think such a rendering
 stylesheet should differentiate between signed and unsigned refs.  Anyway,
 using something like ref:unsigned=OH 315C to mean this road is part of
 Ohio state route 315C but the signs don't say so sounds perfectly sane to
 me.

It doesn't sound sane to me.  Either the road has the reference, or it
does not.  I don't think it's relevant whether it's included on a sign
or not.

  Richard didn't say he uses that key *because* it's not rendered; he
 uses it because it makes sense. The fact that it's not rendered on
 general-purpose maps justifies the view that the tag won't cause problems.

It's not rendered because nobody knows about it.  There are only 36
instances of ref:unsigned in the whole world, so it probably was not a
good example to use.  Anyway, shouldn't it be reg_ref (Regional
reference) instead?  Or a relation?

Best wishes,

Andrew

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

Re: [Tagging] Feature Proposal - RFC - Obstacle

[Andrew Errington]

I second the name hazard.  This covers obstacles and dangerous areas.

Any hazard can be shown as a simple icon by any software.  Specific hazards 
can be parsed from the values and shown with a specific icon if necessary.

If a landslide blocks the road, then just break the way.  Routing software 
will then avoid that route.  If the landslide blocks part of the road then 
modify the way to lanes=1, maxspeed=20 for example.  This should cause 
routers to avoid the route except for access.

Best wishes,

Andrew

On Sat, 13 Oct 2012 23:07:49 Konfrare Albert wrote:
 Hi!

 I added the value obstacle=heap (the opposite of hole), that could be
 formed by fallen rocks, debris, etc... --
 http://wiki.openstreetmap.org/wiki/Proposed_features/Obstacle#Tagging (the
 last value for the key in the table)

 Also I added a mention to landslides --
 http://wiki.openstreetmap.org/wiki/Proposed_features/Obstacle#Other_obstacl
es

 Thanks for suggestions and comments.
 Regards

 ALBERT

 2012/10/13 Graham Jones grahamjones...@gmail.com

  Hazard =   for things like broken barriers?   Actually hazard could
  work for things like landslides and fallen trees too?
 
  Graham
 
  from my phone.
  On 13 Oct 2012 11:27, Martin Koppenhoefer dieterdre...@gmail.com
 
  wrote:
  2012/10/13 Peter Wendorff wendo...@uni-paderborn.de:
   Am 13.10.2012 11:28, schrieb Martin Koppenhoefer:
   I'd suggest some additional values:
   * rockfall = some rocks have fallen onto the road
   * guardrail_broken = there is a hole in the guard rail or in a
   retaining wall alongside the road (i.e. you might fall)
  
   -1 for guardrail_broken as part of obstacle. It isn't.
   Do we have anything for danger sources where it could fit?
 
  I agree, what might be an interesting value to add to obstacle is
  landslide (part of the road slipped away, mostly occuring in hilly /
  mountainous terrain)
 
  cheers,
  Martin
 
  ___
  Tagging mailing list
  Tagging@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/tagging
 
  ___
  Tagging mailing list
  Tagging@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/tagging



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

[Tagging] Hiking trail marker

[Andrew Errington]

Hello,

How should I tag this?  It is a trail marker on a hiking trail in Korea.
http://wiki.openstreetmap.org/wiki/User:Geochang_scribe#What.27s_this.3F

There are several of them, at various points on each trail.  The purpose is to 
indicate where you are on the trail, and also when requesting help due to 
accidents or other incidents to report your location to rescuers.

It's probably related to tourism=information, information=guidepost, but it's 
not quite the same (and we do have conventional signposts here).  I'd almost 
be inclined to invent something like information=trail_marker, but does 
anyone have similar marker posts in other countries?  How are they tagged?

Thanks,

Andrew

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

Re: [Tagging] Feature Proposal - RFC - (amenity=kennel)

[Andrew Errington]

On Thu, 13 Sep 2012 18:00:19 Martin Vonwald wrote:
 2012/9/13  te...@free.fr:
  Thank you for your proposal.
  Couldn't we have some more general tagging for this purpose? Such
  facilities can generally keep other kinds of animals (like SPA,
  Société Protectrice des Animaux in France) so why having a specific tag
  for dogs?

 Actually I just revived an old proposal for stables [1]. My first
 thought was to simply use stables=animal until someone with much
 better english language skills pointed out that stables usually only
 refer to horses. I would also like to see one common tag for some
 place where animals are kept and taken care of. Any suggestions from
 native speakers?

I'm not sure if a common tag would be ideal.

Off the top of my head we have 'stables', 'kennels' and 'cattery'.  Each name 
is very specific.  Also, they are not limited to welfare (lost, abandoned or 
abused animals), there are commercial businesses which look after animals 
while their owners go on vacation.  Since they generally look after the same 
kind of animal (not mixed), this should be indicated by the tag, i.e. 
amenity=kennels, amenity=stables, amenity=cattery

For the welfare situation I suppose we could have amenity=animal_shelter, or 
animal_sanctuary.  These generally do have a mix of animals, but of course 
dogs and cats are most common.  There are also specialist shelters for birds, 
seals, otters etc., but probably animal_shelter would cover those too.

Just my thoughts on the matter.

Best wishes,

Andrew

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

[Tagging] Feature Proposal - RFC - key:branch

[Andrew Errington]

Hello everyone,

This is my first proposal for a key that I feel is missing.  I have searched, 
but I couldn't find anything to suggest it has been rejected before, but I 
could be wrong.

You will find the details here, but is basically a place to put the branch 
name for an office/bank/restaurant/store etc.:
http://wiki.openstreetmap.org/wiki/Key:branch

I think I've done the first steps for this proposal right, and I am quite 
happy to hear all comments, positive and negative.

Best wishes,

Andrew

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

Re: [Tagging] Automated edit of company name change

[Andrew Errington]

On Mon, 03 Sep 2012 18:32:32 Pieren wrote:
 On Sun, Sep 2, 2012 at 9:46 PM, Jaakko Helleranta.com

  You might want to move the old name to, well, old_name=*  .. because many
  may well search for that even years after the name change.

 And if the tag old_name is already present with a previous store name ?

When I look at the data I will be able to see if this is an issue.

Thanks,

Andrew

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

Re: [Tagging] Automated edit of company name change

[Andrew Errington]

On Mon, 03 Sep 2012 22:06:21 Johan Jönsson wrote:
 Andrew Errington erringtona@... writes:
  Thanks everyone for the tips.
 
  I'm sure it's all stores:
  http://koreajoongangdaily.joinsmsn.com/news/article/article.aspx?

 aid=2954734cloc=joongangdaily|home|newslist2

   On Sun, Sep 2, 2012 at 2:30 PM, Andrew Errington erringtona@...
  
   wrote:
   Hello everyone,
  
   Here in Korea a chain of convenience stores has changed its name
   from FamilyMart to CU.  All of the stores have had their signage
   and livery removed and replaced with new signage and livery.
  
   What is the best way to perform essentially a country-wide
   search-and-replace
   for objects tagged shop=convenience, name=FamilyMart to change the
   name to name=CU?  The objects could be nodes or areas.

 I do not want to complicate the matter but if I was to tag those I would
 have used the tag
 brand=CU

 but even then, the name-tag usually get something like CU Garak. So it
 doesn´t solve anything, it just makes things more hard to change.

'CU' is what is on the sign.

If I was going to add something else I might consider operator=BGF리테일 (BGF 
Retail), but this is the sort of thing we need to discuss on talk-ko.

It's sufficient to have shop=convenience, name=CU.  That's all that is needed.

Best wishes,

Andrew

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

[Tagging] Automated edit of company name change

[Andrew Errington]

Hello everyone,

Here in Korea a chain of convenience stores has changed its name 
from FamilyMart to CU.  All of the stores have had their signage and 
livery removed and replaced with new signage and livery.

What is the best way to perform essentially a country-wide search-and-replace 
for objects tagged shop=convenience, name=FamilyMart to change the name to 
name=CU?  The objects could be nodes or areas.

Naturally I want to follow the Mechanical Edit Policy properly, the first step 
being to raise the matter on this list.  I'd like to know how to actually do 
this task, so that when we discuss it on the talk-ko list I know how much 
work will be involved both to do the change, and to verify the results.

It is also quite possible that a Mechanical Edit is the Wrong Answer, and it 
would be better for me to encourage mappers here to coordinate our efforts 
and update different areas by hand.

Best wishes,

Andrew

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

Re: [Tagging] Automated edit of company name change

[Andrew Errington]

Thanks everyone for the tips.

I'm sure it's all stores:
http://koreajoongangdaily.joinsmsn.com/news/article/article.aspx?aid=2954734cloc=joongangdaily|home|newslist2

but the points you all raised are good ones, thank you.  I am now in a
position to talk about what we should do and how we should do it on
the talk-ko list.

Best wishes,

Andrew

On Mon, Sep 3, 2012 at 6:40 AM, Richard Mann
richard.mann.westoxf...@gmail.com wrote:
 Extract all shop=convenience+name=FamilyMart from the Geofabrik country
 extract into an OSM file using osmosis. Load the file into JOSM. Select all
 and edit. Upload.

 I probably shouldn't have told you that. It's a bit too easy to mess things
 up...

 Richard

 On Sun, Sep 2, 2012 at 2:30 PM, Andrew Errington erringt...@gmail.com
 wrote:

 Hello everyone,

 Here in Korea a chain of convenience stores has changed its name
 from FamilyMart to CU.  All of the stores have had their signage and
 livery removed and replaced with new signage and livery.

 What is the best way to perform essentially a country-wide
 search-and-replace
 for objects tagged shop=convenience, name=FamilyMart to change the name to
 name=CU?  The objects could be nodes or areas.

 Naturally I want to follow the Mechanical Edit Policy properly, the first
 step
 being to raise the matter on this list.  I'd like to know how to actually
 do
 this task, so that when we discuss it on the talk-ko list I know how much
 work will be involved both to do the change, and to verify the results.

 It is also quite possible that a Mechanical Edit is the Wrong Answer, and
 it
 would be better for me to encourage mappers here to coordinate our efforts
 and update different areas by hand.

 Best wishes,

 Andrew

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



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

Re: [Tagging] Ford = depreciated?

[Andrew Errington]

I remember this happening, and it seemed like a Good Thing at the time, 
although I had only mapped one ford.

It was suggested that highway=ford should be deprecated and replaced with 
ford=yes.

So ford itself is not lost, it has moved from a value to become a key.

I like this approach.  Do you think it's such a bad thing?

Best wishes,

Andrew

On Sat, 25 Aug 2012 21:37:20 Philip Barnes wrote:
 Have just spotted this changeset whilst looking through changes near me?

 http://www.openstreetmap.org/browse/changeset/12837424

 Why has Ford been depreciated? It is the correct definition, and the
 word used on road signs.

 A google search revealed this wiki page
 http://wiki.openstreetmap.org/wiki/Talk:Key:ford

 This discussion that did go on seems to me disjointed, and is confused
 with stepping stones. Surely if these exist they are a separate node,
 they are usually part of a footway, alongside the road which fords the
 stream, there is also often a footbridge alongside the ford.

 I cannot think of a better tag. Tagging with water=yes just seems like
 we dumbing down.

 Everyone should know what a ford is, and obviously the depth or if there
 is water will depend on the recent weather.

 The decision was made by what appears to have been made by a vote by 5
 people.

 Why has it not been discussed in this mailing list where it will be seen
 by someone who is not searching the wiki for Fords today.

 Phil


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



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

Re: [Tagging] RFC: Names localization

[Andrew Errington]

On Thu, 02 Aug 2012 07:31:40 John Sturdy wrote:
snip
 i.e. London may be London to an English person and Londres to a
 French person, but Stourport-on-Severn is Stourport-on-Severn to
 both of them (just picking a smallish town randomly; no potential slur
 intended).  And a lot of names in OSM are street names; as far as I
 know, it's rare for people from another country to have different
 names for a country's streets.

Absolutely, but the point is whatever mechanism we implement for name=* (and 
name:xx=*) must work for anything that can be tagged with name=*.  If it's 
not needed for something, then it is simply not used.

And actually... in Korea we do have different names for streets, one in Korean 
(in Hangul) and one in English.

Best wishes,

Andrew

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

Re: [Tagging] RFC: Names localization

[Andrew Errington]

On Wed, 01 Aug 2012 19:48:37 John Sturdy wrote:
  [1]
  http://wiki.openstreetmap.org/wiki/Proposed_features/Names_localization

 +1, generally; but I'm not keen on deprecating the bare name=* tag,
 because for many (perhaps most) named features, there is only one
 name.  For example, a minor rural road in England will probably have a
 name (in English), but it won't have names in other languages, and
 no-one will really describe its name as its English name --- it's
 simply its name.  Multiple names are really an issue for
 multilingual countries and for major features (typically large cities,
 rivers, and perhaps mountains) in monolingual countries, and I suspect
 those are well under half of all the features that will ever be
 mapped.

I like the proposal in general, but I don't think it's necessary to introduce 
a lang=* tag, and I don't think we should lose the name=* tag.

It's also not true that in a 'monolingual' country that there is only one name 
for something.  For example, London is 'London' to a British person, 
but 'Londres' to a French person.

I still think it's simple enough to have name=* to be the 'default' name you 
get if you don't specify a language, or the name you get if your selected 
language is not available.

For example, for London:
name=London
name:en=London
name:fr=Londres

Then a person requesting a French version of the map would see 'Londres', but 
a person requesting the German version would see 'London'.  If no language is 
specified a person would see 'London'.

A simple algorithm can also make bilingual maps by concatenating tags, 
i.e. name:xx (name:yy) and making sensible decisions if name:xx=* or 
name:yy=* is missing, or if name=* contains name:xx=* or name:yy=* (such as 
in Japan or Korea where name=* contains Japanese (or Korean) followed by 
English in brackets).

Best wishes,

Andrew

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

Re: [Tagging] drinkable vs. drinking_water

[Andrew Errington]

On Fri, 13 Jul 2012 21:45:03 Ronnie Soak wrote:
snip
 I do understand 'potable' and I believe others can do too. You either
 use translated presets or need to look it up in the wiki/taginfo
 anyway. I also expect anyone smart enough to use an osm editor can
 also use a translation tool.
 BUT: I don't think migrating existing tags helps anyone. As long as
 the alternative is as understandable as 'drinking_water', my vote is
 for keeping the existing term.

The problem is that there are two existing terms.  The original poster (OP) 
asked for suggestions to unify them.

It would seem the options are to delete one of them and migrate the tags to 
the other one, or create a new one and migrate them both.

Migrating them both was my suggestion, but it seems that 'potable' is not a 
new suggestion.

I think that we should first agree that they *should* be unified (which I do 
agree to) *then* decide how to unify them.  OP says that drinkable=yes/no 
has more usage than drinking_water=yes/no, but my suggestion avoids the 
need to argue about, sorry, choose which one to delete.  It is also more 
concise.

If we don't use 'potable' I think 'drinking_water' is preferable 
to 'drinkable'.

Best wishes,

Andrew

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

Re: [Tagging] drinkable vs. drinking_water

[Andrew Errington]

On Thu, 12 Jul 2012 21:21:34 Martin Koppenhoefer wrote:
 The general tag for a source of drinkable water is
 amenity=drinking_water. But in some cases you will want to subtag an
 existing OSM-object (like an amenity=fountain) with the info that the
 water is drinkable.

 Apparently our free tagging schema has led to 2 alternative keys for this:

 drinkable=yes/no can be found here:
 http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfountain

 drinking_water=yes/no is defined here:
 http://wiki.openstreetmap.org/wiki/Key:drinking_water

 The first is around 5 times more in use than the second. How shall we
 proceed in order to unify the two?

Can we introduce potable=yes/no and migrate both of those tags to it over 
time?

Best wishes,

Andrew

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

Re: [Tagging] drinkable vs. drinking_water

[Andrew Errington]

On Thu, Jul 12, 2012 at 10:46 PM, Janko Mihelić jan...@gmail.com wrote:
 2012/7/12 Andrew Errington erringt...@gmail.com

 Can we introduce potable=yes/no and migrate both of those tags to it
 over
 time?


 I don't know if this is for consideration, but the word potable is not
 very known outside english speaking countries (and maybe french, because it
 comes from a french word). Why not drinkable=official/yes/no?

I expect that trunk road, roundabout, shelter and
archaeological site are not well known in all languages, however,
the language of OSM is English and potable has a very clear meaning.

Petrol, or gasoline, is drinkable, but you shouldn't do it.

You could dumb-down the meaning in the dialog that asks Is this
drinking water? and set potable yes/no.  You can dumb-down the
rendering and make it display 'drinking water' if potable=yes.  You
can even translate the tag, so that in the database we use
potable=yes/no, but in the user interface we show the local
equivalent.

Furthermore it's trivially easy to learn the meaning of a tag by
looking in the wiki.  If you don't know what potable=* means then look
it up.  If it's not listed in the wiki in your language- add it.

The language of OSM should be precise.  If it's not then people start
inventing tags that have similar, but imprecise meanings, which is
exactly what has happened here.

Best wishes,

Andrew

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

Re: [Tagging] drinkable vs. drinking_water

[Andrew Errington]

On Fri, Jul 13, 2012 at 10:01 AM, Tobias Knerr o...@tobias-knerr.de wrote:
 On 13.07.2012 02:12, Andrew Errington wrote:
 I expect that trunk road, roundabout, shelter and
 archaeological site are not well known in all languages, however,
 the language of OSM is English and potable has a very clear meaning.

 Wikipedia seems to think that potable water and drinking water mean
 the same thing, though.

Then you won't mind using potable, since they are the same.  :)

What's the difference between 'water' and 'drinking water'?  Answer-
'drinking water' is water that is potable.

Anyway, I don't think we should assume other people are stupid and
choose 'simple' words just for the sake of it.  It seems that we all
know what potable means, but we are worried that other mappers, whom
we have never met, won't understand.  Let me assure you, they are just
as smart as you.

Best wishes,

Andrew

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

Re: [Tagging] Mapping larger Mini-roundabouts

[Andrew Errington]

On Wed, 06 Jun 2012 18:32:59 Colin Smale wrote:
 On 06/06/2012 09:13, Martin Vonwald wrote:
  If you want to specify the dimension of the mini-roundabout I think it
  would be sufficient to specify the width of the approaching roads.
 
  Martin

 How about diameter=15 on the mini-roundabout node? This is factually
 correct, verifiable on the ground and (IMHO) non-controversial; routing
 would not be affected (no need to route over areas) and renderers can
 draw a bigger blob. Problem solved, simples.

If we do this I would really love to see the tag as radius=* instead of 
diameter=*.

Thank you,

Andrew

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

Re: [Tagging] Mapping larger Mini-roundabouts

[Andrew Errington]

On Wed, 06 Jun 2012 21:21:56 Philip Barnes wrote:
 Diameter is more universally understood by the layman than radius.

You and I both seem to understand it.  Let's not underestimate the ability of 
someone we haven't met.

 Radius 
 is normally only used by engineers, scientists and mathematicians.

...which is why it's a better choice.

 Plus it 
 keeps us from having to map fractions.

A diameter could have a fractional part, although we would use a decimal 
point.

Best wishes,

Andrew

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

Re: [Tagging] Mapping larger Mini-roundabouts

[Andrew Errington]

On Wed, 06 Jun 2012 21:25:08 Tobias Johansson wrote:
 Concerning diameter/radius. What if the mini-roundabout isn't round?

It is.  It is a perfect circle on a frictionless plane.

But if it's not, use the minor radius, then calculations can be done for the 
worst case (large vehicle, smallest angle turn).  Besides, no-one is going to 
go out with a tape measure.  It's going to be eyeballed, or estimated from an 
aerial photo.

Best wishes,

Andrew

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

Re: [Tagging] Mapping larger Mini-roundabouts

[Andrew Errington]

On Wed, 06 Jun 2012 22:06:10 Philip Barnes wrote:
 Mini roundabouts are normally too small to be anything but round.

 I realise that we would use decimal s rather than fractions. But in most
 cases a guestimate of diameter in metres will do. Most will be either 1, 2
 or 3 metres, using radius there will be a lot that are radius of 0.5m.

A vehicle is about 2m wide, so the smallest mini roundabout (a regular 
two-way, two lane road with a dot painted in the middle) would have a radius 
of 2m.

 And I refuse to try measuring the ones on the A53 with a tape measure
 ;)

I'll hold one end for you?

Andrew

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

Re: [Tagging] Mapping larger Mini-roundabouts

[Andrew Errington]

I propose that the radius would be from the centre of the
mini-roundabout to the centreline of the road around it.

And to the previous poster who said that diameter would be better as
it is hard to estimate the centre, I agree in general, but in this
case we specify precisely where the centre is (it's the lat/lon of the
node).  I assert that centre + radius is the correct way to define
this.

Best wishes,

Andrew

On Wed, Jun 6, 2012 at 11:15 PM, Richard Welty rwe...@averillpark.net wrote:
 On 6/6/12 10:03 AM, Philip Barnes wrote:

 There are lots that have 2m diameter, 1m radius, such as this pair in
 Loggerheads http://goo.gl/NknP.

 Have seen some smaller but can't place any from memory.

 http://goo.gl/NknP – this URL has been disabled.

 i don't understand how a 2m or smaller diameter entity can qualify as a
 mini-roundabout for
 motorized vehicular traffic (at least, the 4 wheel kind.)

 or are we talking about 2 different diameters here? the outer diameter of
 the circle vs the
 diameter of the usually untraveled center?

 richard


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


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

[Tagging] Light-rail station

[Andrew Errington]

Hi all,

This light-rail station is above ground near an airport in South Korea.

http://osm.org/go/546KGWeqC--?m

I originally mapped the light rail (two tracks) and added a node at
each station point (so, two nodes per station, one in each direction).

A new mapper has done a nice job of the airport carpark, but has drawn
the station building outline and deleted the two sections of track
that went through it and one of the station nodes.  However, they have
added the building outline to a relation which represents the route.

Is this right?  Is there a better way?  Shouldn't the track be
continuous through the station building?

The reason for asking is that I'd like to show all station buildings
on this line like this.  They are mostly rectangular boxes with the
tracks running through, like this:

http://en.wikipedia.org/wiki/File:Gimhae_lightrail_station.jpg

If everything is mostly ok what I'll probably do is copy the station
node tags to the building outline and delete the node.

Thank you,

Andrew

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

Re: [Tagging] Another reset on roundabouts

[Andrew Errington]

On Fri, 18 May 2012 18:06:54 Richard Fairhurst wrote:
 Andrew Errington wrote:
  It's easy to edit the wiki.  It's easy for Potlatch and JOSM
  developers to edit the software to do the Right Thing.
  How do we make this happen?

 I like your it's easy statement, and look forward to you publishing
 details of where one can get the 40-hour day which will enable us happy
 Potlatch developers to do all the it's easy stuff that people would like.

Assuming it is a desirable thing, how do we make it happen?

Best wishes,

Andrew

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

Re: [Tagging] Another reset on roundabouts

[Andrew Errington]

On Fri, 18 May 2012 16:38:09 Martin Vonwald wrote:

 Do you have any suggestion how to change the presets for
 mini-roundabouts? The term mini-roundabout is very misleading so we
 need some very good, crystal clear and short description for it. Any
 idea is very welcomed!

I think the term 'mini-roundabout' is not at all misleading.  It's the name 
given to a very specific thing in the UK.  What we need is clarification in 
the Wiki and maybe language-specific or country specific terms.  For example, 
a list of countries where mini-roundabouts never appear, or a list of common 
mistakes when attempting to identify mini-roundabouts to help people identify 
them properly.  The Wiki page looked good last time I checked.  I will look 
again on Sunday.

Best wishes,

Andrew



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

Re: [Tagging] Another reset on roundabouts

[Andrew Errington]

On Fri, May 18, 2012 at 7:21 AM, Toby Murray toby.mur...@gmail.com wrote:
 Otherwise we can pontificate all we want on the mailing list but
 people who are not familiar with the concept of a real
 mini-roundabout WILL still use this tag for small roundabouts with
 non-traversable centers. That's just reality. Maybe change the display
 label to traversable roundabout or something?

If the definition is clear in the wiki then there should be no
problem.  Anyone discovering something in the database that does not
match the definition is free to correct it.

In real life the definition is quite clear.

We have two distinct nouns, 'roundabout' and 'mini-roundabout'.
Although 'mini-roundabout' is made from two words which have a
well-understood meaning, the compound word has its own specific
meaning.  Adding a further definition (such as 'traversable
roundabout') is not necessary, since, by definition, a mini-roundabout
is traversable, and a roundabout is not.  Furthermore, it is very
clear to me what these two tags would mean on a node.
'Mini-roundabout' on a node means this this a mini-roundabout.  It is
small, and it is traversable.  'Roundabout' on a node means this is a
small roundabout, but it was too much effort (or too tedious) to draw
a circular way.  It is not traversable, and traffic must 'go around'
it based on the local rules for direction and giving way.  Anyone who
discovers 'roundabout' on a node is free to re-draw it as a small
circular way.  The net effect to routing should be negligible.

I think the problem is that we use 'mini-roundabout' with highway=*
and 'roundabout' with junction=*.  In my opinion they should both be
junction=*, with 'mini-roundabout' restricted to nodes, and
'roundabout' applicable to nodes or circular ways.  Furthermore, when
applied to a node we should probably encourage the tag direction=*
although some software can probably figure that out.

Best wishes,

Andrew

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

Re: [Tagging] Another reset on roundabouts

[Andrew Errington]

So, I know what a mini-roundabout is, and you know what a
mini-roundabout is, and we are in agreement.  You have also identified
specific problems with the editing software that guides people to the
wrong conclusion if they don't know what a mini-roundabout is.

It's easy to edit the wiki.  It's easy for Potlatch and JOSM
developers to edit the software to do the Right Thing.  How do we make
this happen?

At the end of the day it doesn't really matter.  If something is
tagged wrongly nobody dies, and someone who knows better can come
along later and fix it.  It would be nice if we could make it easy to
do something the right way first, but fixing it up afterwards is not
too difficult.

Best wishes,

Andrew

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

Re: [Tagging] Dispute prevention: meaning of lanes tag

[Andrew Errington]

On Mon, 30 Apr 2012 00:29:52 Kytömaa Lauri wrote:
 Before that I added a point in the Open issues section about lanes=1.5
 and modified the note at the end of the section Narrow road. As

 So, today I got a chance to revisit an unpaved residential road
 I've tagged as lanes=1.5 in the distant past. Here's two
 pictures of it (in one)

 Above, usual traffic drives almost in the center of the road,
 as if it were lanes=1.

 Below, the car in picture has it's right side mirror almost
 touching the fence, and there's 2.2 meters of the
 carriageway free for oncoming traffic, 2.6-2.7 meters
 of space to the fence on the other side of the road.
 Oncoming cars can get past each other, so it's not
 lanes=1. Yet all driveers will slow to a crawl, or at least
 to a jogging speed, so IMO it can't be lanes=2,
 either.

 http://i46.tinypic.com/2cfqivn.png

 Which value would people use for the lanes=*?

Sometimes the answer is It doesn't matter.

If you tagged it with lanes=1, but not oneway=yes, then it's clearly a 
bottleneck and should be avoided by routers.

If you didn't tag lanes=* at all and you didn't have oneway=yes then my 
assumption would be lanes=2 (because it's not one way).  Or you could tag it 
explicitly with lanes=2. Either way, map users would probably complain that 
it's too narrow for certain types of vehicle, so it should be re-tagged 
lanes=1.

If you tagged the width then it wouldn't matter if it was lanes=1 or lanes=2 
because we can see the overall width and use heuristics to decide if it's a 
slow road or 'normal' road.

Furthermore, if it's classified as highway=residential that would be a hint 
that it's a narrow road not to be driven too fast.

Any of these factors, either assumed, or explicit, should be used by a route 
planner to make this road unattractive for routing.

It's very tempting to add explicit values for every tag, but I really think 
sometimes it just doesn't matter, and we can get the same meaning for 
combinations of other tags (even if the tags are absent).

Best wishes,

Andrew

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

Re: [Tagging] Dispute prevention: meaning of lanes tag

[Andrew Errington]

On Mon, 30 Apr 2012 00:29:52 Kytömaa Lauri wrote:
 Before that I added a point in the Open issues section about lanes=1.5
 and modified the note at the end of the section Narrow road. As

 So, today I got a chance to revisit an unpaved residential road
 I've tagged as lanes=1.5 in the distant past. Here's two
 pictures of it (in one)

 Above, usual traffic drives almost in the center of the road,
 as if it were lanes=1.

 Below, the car in picture has it's right side mirror almost
 touching the fence, and there's 2.2 meters of the
 carriageway free for oncoming traffic, 2.6-2.7 meters
 of space to the fence on the other side of the road.
 Oncoming cars can get past each other, so it's not
 lanes=1. Yet all driveers will slow to a crawl, or at least
 to a jogging speed, so IMO it can't be lanes=2,
 either.

 http://i46.tinypic.com/2cfqivn.png

 Which value would people use for the lanes=*?

Sometimes the answer is It doesn't matter.

If you tagged it with lanes=1, but not oneway=yes, then it's clearly a 
bottleneck and should be avoided by routers.

If you didn't tag lanes=* at all and you didn't have oneway=yes then my 
assumption would be lanes=2 (because it's not one way).  Or you could tag it 
explicitly with lanes=2. Either way, map users would probably complain that 
it's too narrow for certain types of vehicle, so it should be re-tagged 
lanes=1.

If you tagged the width then it wouldn't matter if it was lanes=1 or lanes=2 
because we can see the overall width and use heuristics to decide if it's a 
slow road or 'normal' road.

Furthermore, if it's classified as highway=residential that would be a hint 
that it's a narrow road not to be driven too fast.

Any of these factors, either assumed, or explicit, should be used by a route 
planner to make this road unattractive for routing.

It's very tempting to add explicit values for every tag, but I really think 
sometimes it just doesn't matter, and we can get the same meaning for 
combinations of other tags (even if the tags are absent).

Best wishes,

Andrew

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

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

Re: [Tagging] Dispute prevention: meaning of lanes tag

[Andrew Errington]

I'm quite happy with lanes=n where n is an integer.

I am very happy to assume that a one-way road without lanes=* has only one 
lane.

I am also happy to assume that a not-one-way road without lanes=* has two 
lanes (one in each direction).

I am extremely happy to see a width=* tag that I can use in conjunction with 
the lane count (even if the lane count is assumed).  It tells me the width of 
each lane.

A lane count of 1.5 is very confusing.  What does it mean?  What is the width 
of each lane?  Is it really 1.5?  Should it be 1.55, or 1.4, or 1.6?  It's 
more useful to tell me width of the road.  Then, if there is one lane I can 
see maybe it's very wide, or if two lanes I can see maybe they are very 
narrow.  It's okay to let me assume the number of lanes because the 
assumption is safe, and if it's really wrong then someone will tag it 
properly later.

In summary, I think simpler is better.  A non-integer lane count is useless.  
Use the width tag.

Best wishes,

Andrew

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