Re: [Tagging] Help explain the difference between path and track

[Lauri Kytömaa]

>A track does have a different function, it can handle a 2 track vehicle, a 
>path can't.

If there's something even remotely like that in the wiki, help or elsewhere, it 
needs to be reverted to what it has been from the beginning. all we can say is: 
A track can't be so narrow it can't handle a two tracked vehicle.

All ways will have exceptional use cases (emergency, maintenance) - even if a 
stranded motorist or tow truck driver walks on a motorway, that doesn't mean it 
isn't a motorway where walking is forbidden and likewise, if the city lawnmower 
drives on a highway=path once or twice every year, that doesn't make it a track 
or service.

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

Re: [Tagging] How to tag oneway restriction applying to pedestrians?

[Lauri Kytömaa]

>(a path is too narrow for a motorcar, so

That's a common misdescription. A track can't be so narrow a car wouldn't fit, 
but most built highway=path ways are wider than that.

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

Re: [Tagging] Public transport cards

[Lauri Kytömaa]

Warin wrote:
>Marc Gemis wrote:
>> bus/bike/train routes. Something no PT provider can offer as they only
> Never say never?
>
> A PT provider with multi modal planer - bus, train, light rail  and ferry
> for Sydney, Australia
>
> http://www.transportnsw.info/

Fwiw, we've had a country wide bus-train-airplane router for years
http://www.journey.fi/en/ although I'm not absolutely certain it has local bus
timetables for each and every small town that might have some bus lines;
just one such place is listed currently.
It has an updated version in public beta,
like this (doesn't seem to support linking to a specific UI language):

https://beta.matka.fi/reitti/Toukola,%20Helsinki::60.208836,24.972565/Levintie,%20Kittil%C3%A4::67.724127,24.854204

(If you only get one route suggestion, you get more by changing the
departure time to noonish.)

-- 
alv

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

Re: [Tagging] Hunting area tagging

[Lauri Kytömaa]

Martin Koppenhoefer wrote:
> if the forest and the hunting area are known under different names, under 
> which tag would you put which name?

Two points for the whole discussion thread:

1) Forest areas (with the tag, that is) can be subdivided for various
attributes, like deciduous/coniferous/last_full_chop=* etc. Users
could debate for months when it is appropriate or isn't, but they are
already.

2) Areas where hunting is allowed (to some) are not usually directly
tied to the edges of the landuse=forest ways, even if the forest
polygon hasn't been subdivided. Hunting (as in the general meaning
"somebody shoots animals") isn't limited to forests.


-- 
alv

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

Re: [Tagging] Tagging an area for seasonal snowfall?

[Lauri Kytömaa]

Martin Koppenhoefer wrote:
>> http://wiki.openstreetmap.org/wiki/Key:seasonal:snowfall:regaintime
>
> this looks like a completely useless tag to me, or at least misleading and
> prone to guesswork and phantasy mapping. If I understand it right, the tag
> tries to say something about the usage frequency of footways in the winter,
> but uses quite subjective criteria and has a lot of undeterminable variables
> in it (e.g. how much snow in what time, what are the temperatures (because
> lower temperatures will lead generally to less people walking, just as will
> precipitation, while sunny weather will encourage more people to go outside,
> also walking). From my own experience, ways are more "easily walkable in
> dress shoes" if you're the first to use them (but this might depend on the
> amount of snow), while ways that get used a lot have to be treated or will
> become slippery ice ways soon. etc. etc.

Hi,

I believe I need to say something about this, because most of those
have been entered by me. I did consider, and discuss this with other
local mappers long ago when we tried to consider what can we say
about ways that aren't snowplowed, but are evidently valuable routes
because they... are used anyway, whereas the next one isn't.

If there's so little snow that you can easily walk in dress shoes as the
first pedestrian after the snowfall, the way never had to be "regained",
there's just a shallow white cover that doesn't impede on your travel.

Temperature has nothing to do with it, in the sense that if it gets colder,
even if there's generally fewer pedestrians, the preference between
snowplowed and various possibly shorter but practically blocked with
snow ways stays the same - to a large extent anyway - and it's not the
same as the year-round usage frequency. Once days have passed
since the last snowfall, most - but not all - ways likely have turned to a
solid surface from walking, and are again as good a choice as the
next one.

The point is that the usage frequency changes from the non-snow
conditions in a predictable and mostly repeatable manner when there's
enough new snow that unless the way is snowplowed, people rather
take a detour - except if it's a valuable shortcut (valuable for some
reason, which we don't need to care about), it's regained first. As
another example, an unmade forest trail in the city park might not be
traversed on foot the whole winter, or it might be the most popular path
taken by dog walkers throughout the winter and practically always
"open", despite not seeing any snowploughs. It's even easier to verify
than the amount of route users, because you only need a few samples
after separate days of snowfall to see which ways have already been
regained on every occasion, and which seem to be forgotten until the
spring comes (and few values between those ends of the axis).

-- 
alv

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

Re: [Tagging] Path with permit required for bikes?

[Lauri Kytömaa]

Richard Fairhurst wrote:
> An important part of the Pacific Coast Bicycle Route now requires cyclists
> to get a permit:
> It's not quite 'bicycle=permissive' - that's generally used to imply that
> bikes are allowed in by goodwill of the landowner but don't have to book,

If we could stick to the original list of values, that does look like
'private' to me: the land owner has the right to ban access and
has used that right, and only those who know they have a
permission from the land owner may use it. "If you don't know
better, you can't cycle there."

The fact that/if they generally don't refuse the individual permit
when applied for in advance (assuming you're a US citizen) isn't
relevant for the actual access/bicycle tag, but should be recorded
with some other tag; your idea of
reservation:bicycle=required is as good as any other so far. Or:

private:bicycle:licence=MCB CAMPEN Bike Route

Which identifies the ways where the permit is valid, and gives
something to search for if nobody starts a site listing contact
points for various licence issuers, and tells the reader that the
tagged licence relates to cycling, and to the fact that a group
of cyclists exists holding licences from the owner of the private
area. I'd guess that the details of who can get a licence and how
fast - not just there but globally in similar situations - are so
complex that at best the ways would have incomplete, unusable
data and consumers would still need to check directly with the
permit issuer to see if they're eligible.

If there's ever a case for overlapping licences, semicolons,
multi value keys and relations can be (again) discussed
ad infinitum.

-- 
alv

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

Re: [Tagging] natural=wood status=approved?

[Lauri Kytömaa]

On Thu, Feb 4, 2016 Warin wrote:
>  The wiki page for natural=wood has the status shown as 'approved'.
> This was set to 'approved' on 20th May 2010.

Many major basic tags were included in a list written in I-believe-it-was
2006, i.e. on the original Map Features page. The tag status templates,
tagging list, and even the idea of proposed features was conceived
later than many basic tags that just about everybody uses. FWIW,
before the tagging list existed, the discussion on new tags took place
on the "talk" list.

-- 
alv

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

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Lauri Kytömaa]

On Wed, Mike N wrote:
> On 1/20/2016 3:39 PM, Dominic Coletti wrote:
>> I see 808,000 uses of name_1 and 65,000 of name_2.
> Many of these are from the US TIGER import, and must not be automatically
> removed.  They would go into alt_name , etc based on local knowledge.

I believe this is a good point to make, the origin for many of those tags.
While the number of uses is reason to keep them as-is, if a major slice
of them comes from an import, the ratio isn't a good reason to *recommend*
entering more of them.

Browsing through this thread I didn't notice one point, the fact that with
alt_name=a;b;.. all the names are/should be in the semicolon separated
list, i.e. even without any processing that separates the parts/names into
distinct records, searching would indicate that the searched-for name is
within the list of alternative names (in most cases/some countries, not
doing some sort of wildcard matching gives a bad user experience, esp.
if the local word or abbreviation for "street" is always at the beginning).
With name_1 and name_2 and name_9 you'd never know how many tags
you have to look for when indexing the db dump and changes.

Also, with name_[n] the original mapper and the next mappers have to
order the names with reasoning or just how they like them (subjective),
whereas with name=The Name + alt_name=other names the alternative
names are then equal with each other (a collection of alternative names).
What should be in the plain name tag is easier to agree on (especially if
the operator behind the named entity can be asked), than it would be to
agree on the sorting of the other known names.

-- 
alv

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

Re: [Tagging] key:priority

[Lauri Kytömaa]

On Wed, Jan 20, 2016 at 7:12 PM, Paul Johnson wrote:
> http://wiki.openstreetmap.org/wiki/Key:priority
>
> Would there be any major objection to expanding the priority key to include
> two way, multilane situations?  Example would be a two way street that was
> formerly a one-way street, and has signal timings as if it were a one-way
> street (thus the green wave turns into the red crawl if you're going the
> direction opposite the de-facto priority).

I'd rather keep that key solely for cases of "legal" priority of one direction
on the road segment in question. Both might effectively slow you down, but
in the "legal" case driving there is a different from "just slow" red
light crawl.

There have been some proposals in the past in the wiki for various
approaches to recording the fact that the delays are higher than could
be normally expected, but I'm not aware of any of them ever having
gained any support.

-- 
alv

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

Re: [Tagging] time-conditioned turn restriction

[Lauri Kytömaa]

Martijn van Exel wrote:
> type=restriction;restriction=no_left_turn; no_left_turn:conditional=no @
> (Mo-Fr 06:00-09:00,16:00-19:00)
>
> Is this the preferred way? Should it be?


type=restriction
restriction:conditional=no_left_turn @ (Mo-Fr 06:00-09:00,16:00-19:00)

There's also a mention of "none" for conditional restrictions (the format,
not turn restrictions), so a possibly better way to encode this would be

type=restriction
restriction=no_left_turn  (error on the side of caution, if times aren't parsed)
restriction:conditional=none @ (Mo-Fr 09:00-16:00, 19:00-06:00; Sa-Su 24h)


-- 
alv

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

Re: [Tagging] amenity=bicycle_repair_station

[Lauri Kytömaa]

>> What ambiguity of repair_station would be cleared by tool_stand or
>> tool_station ?
> it is the word "station" that could be interpreted as a shop / service
> station. "stand" does not bear this risk (for me). "tool_station" would be

Additionally, "repair" does not state who does the repairing (cyclist or
hired help), but "tool" should guide the readers focus on the availability
of tools, not on the action.

-- 
alv

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

Re: [Tagging] How to tag a "overhead electronic display" ?

[Lauri Kytömaa]

johnw wrote:
>> traffic_sign=changing
>> or
> >traffic_sign=variable
> The matrix displays and variable signs are very different.

> a matrix sign can become entirely different signs. They are also a  source
> for alerts and current info no matter the topic - whereas a variable sign
> for the speed limit is pretty limited to displaying a number value, or a

For what it's worth, the displays that started this thread are not
"traffic signs" in the sense that they don't show anything that a
driver must obey or even comprehend, but they only show info on
air and road temperature and traffic delays, sometimes textual
messages if an accident or roadworks ahead affect available
routes or capacity. The "real" variable traffic signs are similar to
those jonhw describes, that they can only display a limited set
of signs, which can affect the speed limit. I'd rather see that these
info displays are not traffic_sign=*, but anything else goes.

-- 
alv

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

Re: [Tagging] More human readable values for traffic signs

[Lauri Kytömaa]

André Pirard wrote:I think he is referring to the "do not enter" sign, a
red circle with a horizontal white bar.

>The rectangular F19
 is
disputably classified as "information"
>The no-U-turn sign C33
 might be
thought of as one-way, but
>There is no round one-way sign that I know of.  But, of
>course, a follow the direction
ahead
D1
 placed
withing a street

The osm ways do and can not match one-to-one with traffic signs.
The tag oneway=yes on an osm way does not only mean "this is
a _road_ with a oneway sign", but "traffic should not traverse this
way in the backward direction". For the simplest example, most
dual carriageway roads do not have a oneway traffic sign on either
carriageway, they might not even have a "no entry" sign for the
opposing direction carriageway (just a "pass this sign/obstacle on
the right" at the intersections, if even that).

Even the no entry (round red sign with a yellow/white horizontal
rectangle) sign _effectively_ makes a short section oneway: every
vehicle has length, so at some point coming from the "oneway"
direction, there's at least a small (but several meters) distance
where they aren't allowed to turn around - if they did, they would
unavoidably pass the no entry sign.

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

Re: [Tagging] power=* tag: minor_line vs. line

[Lauri Kytömaa]

David Marchal wrote:
> I saw conflicting points of view regarding the difference between these two
> ways for modelling aerial power lines: some say that it is the voltage which
> matters, others say that it's the visibility difference that matters, others

Hi.

To properly understand this issue, here's the history of the tags:
- originally, in 2006, there was just the page Key:power (then under the
title "Proposed features/Power Lines") with discussions specifically
agreeing that the project should use a different tag for "large" lines
"strung from latticework pylons" and other lines. At that time, nobody had
seriously thought about ever mapping the smaller ones, and it is a common
separation on all pre-OSM maps (and their source data). Being a global
project, "latticework pylons" referred to the type of construction common in
the countries where the early mappers resided, so even if other countries
used different constructions for high voltage lines, they would still be
power=tower. The original description/proposal
http://wiki.openstreetmap.org/w/index.php?title=Key:power=6410
and after discussions agreeing:
http://wiki.openstreetmap.org/w/index.php?title=Key:power=17349#Notes

Power=pole was suggested already in November 2006 for support structures
smaller than power=tower (in the link above)

- in July 2007 the descriptions of power=line and power=tower were copied
to the Map_Features. Still, the assumption and the practice was that people
didn't map "smaller" power lines at all; even if the description of 'line' only
referenced "the path of power cables", it was assumed they'd only be drawn
between power=tower nodes, i.e. only high voltage lines on "big" pylons.
http://wiki.openstreetmap.org/w/index.php?title=Map_Features=39342=39308

- in January 2008 pages were created for
* Tag:power=tower, with the sentence still present "Should not be used for
electricity or telephone cables carried on single wooden pole."
* Tag:power=line, which still had a description referencing "way following
power cables"
* Key:power was changed to reference the template Map_features:power,
with no change in wording
- In March 2008 some had discussed on the osm talk list that minor
lines could be mapped with a different tag.

- following my question in September 2008 on Talk:Key:power, minor_line was
suggested and others started using it, too, if they hadn't already
prior to that.

- in January 2009 the suggestion to use minor_line for "minor lines with poles
and not towers" was added to the list template, as well as
http://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:power=next=206851

- In July 2009 rendering minor_line was already discussed on the talk-de mailing
list.

- in January 2010 the values minor_line and pole were added to the
list template,
after they had proved to be used.
http://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:power=401683=344715

In June 2011 some user(s) wrote a proposal to change everything above ground to
'line' and use other tags with an unlimited list of values for
describing their differences.
http://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Power_transmission_refinement=652518
After discussions and a wiki vote such a change was even rejected in
October 2013,
and the next modified proposal (Power supports refinement) for
redefining power=tower
and power=pole was turned down in May 2015. There is no method in osm to have
the mappers resurvey, reclassify and retag the old data at a whim, nor
a method to
propagate the changes in the contested meaning of tags to (even unknown) data
consumers.

(Digging up these dates I did see a "(overground)" thrown in the
'line' definition to
clarify, but already lost where it was originally. )

In summay, the tags have been used for 9 years as such:
- power=tower: high voltage towers, usually steel latticework
- power=line: overhead lines on strung on high voltage towers
- power=pole: smaller supports, usually one-legged and/or wooden
- power=minor_line: other overhead power lines that don't qualify as power=line
Do note that even if a 'minor_line' has two bigger towers in the
middle, for example to
cross a river or similar, the line as a whole is still minor_line. The
border case of a
remote mapper using the wrong tag for a line or minor line wrongly
identified from aerial
imagery is no different from remote road classification: the local
mappers can and will
correct it later.


-- 
alv

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

Re: [Tagging] Shop values review

[Lauri Kytömaa]

Daniel Koć wrote:
> discount
> flooring
> games
> health_food
> hobby
> tiles
At least these are probably or possibly locally referred to as they
are tagged, Maybe someone can come up with fitting but more general
values, if there are any. If a shop sells mostly only games, it's a
shop selling games.

For the second list, at least some replacements seem incorrect:
> Candidates for deprecating:
> health - medical_supply?
Probably different, first one could be a unlicenced selling products
with (un)claimed health, performance, sleep or other benefits and
whatever, nothing medical about them.

> interior_decoration - houseware?
Houseware seems to refer to "usable" equipment, but I'd assume
interior decoration is anything from curtains and pictures to flower
vases and pillows, possibly with some cabinets and storage boxes in
the mix.

> sewing - maybe tailor?
I've seen a sewing supply shop, yarn, tools and some textiles and
stuffing material, or the like. They won't sew anything for you, like
a tailor does.

> shopping_centre - mall?
The wikipedia page lists regional differences and I'm no native, so
the words themselves may not refer exactly to these attributes, but
the way I read it a year or several ago there is a difference, even if
many might use the words interchangeably. They're almost similar, but
some professionals and others make the distinction that in a mall the
distinct shops are within a single (enclosed) area, but in a shopping
centre the shops have their main entrances from the outside. In the
other, you (almost always) first enter the mall, then the shops; in
the other, you (can) enter the shops directly; or in a mall you go
around with what you bought and then return to your car, but in a
shopping center you're more likely to take your bags to the car
between visits to different shops. It might be that discussing what
the two words really mean would never end, but the difference in
concepts exists.

> souvenir - gift?
Although somewhat similar, I wouldn't got to souvenir shop to buy
gifts for my relatives, they only sell stuff that gives tourists a
cliché memory of the attraction, city or country. As a tourist, I
wouldn't go to a mainstream gift shop business (as WP calls them) to
buy a t-shirt with the name of the city I was visiting; they probably
wouldn't have such.

-- 
alv

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

Re: [Tagging] Delete not marked walking routes?

[Lauri Kytömaa]

Frederik Ramm wrote:
> Our general rule is that things we map must be verifiable on the ground,
> i.e. someone who goes there must be able to check that the feature does
> indeed exist as described in OSM.

This message isn't really contradicting what you wrote later in the
message, but I have to remind others that verifiability doesn't need
to be easy, or it might not even be possible without expert knowledge,
equipment or reference to "other" material not directly present in the
location being mapped.

As a counterexample, let's consider an underground water or heat
pipeline in the city; these are constantly being repaired, improved
or preemptively replaced. A mapper sees the open repair pit on a road,
interpolates the pipeline's location and turns with other known features
and imagery getting the accuracy down to, say, 50 cm. A month later,
the next mapper would only see the patched pavement, and possibly
some manhole covers far or very far apart; only the general alignment
can be inferred. Then, a year later the whole street is repaved, and
only the manhole covers remain, but one couldn't know (for some level
of certainly) whether they belong to pipelines crossing the street, or
whether one pipeline runs along the street, unless one surveys the
whole neighbourhood. Nobody is however suggesting the pipeline
should be removed, or turned into a straight line just because every
casual mapper can't verify the form and attributes on site.

In fact, even administrative boundaries can be verified "in place",
in theory, but it would normally take a whole lot of time and incur
expenses: build an illegal shack anywhere near the border, and wait
for the officials to react, and read the papers you get to see which
area you were in. And that could be costly. Likewise, national borders
can be verified by doing something that attracts the interest of the
enforcement authorities (police, border guard, military); when you see
which country they serve, you know which country you were in. That's
hardly "not present" on the ground.

> "official" bike routes
>...
> (if not fully
> signposted) by a national body, they were ok to have in OSM. They
> wouldn't always be verifiable on the ground but it would be easy and
> straightforward enough for anyone to verify them using existing material.

Back on the topic of this thread, the unmarked but published routes,
I would be on the inclusive side, (roughly drafting) "as long as the exact
route is or has been used for the same purpose by several parties (n>>2)
on different dates, and is not the only connection between two destinations"
or something like that. This would rule out the personal dog walking routes,
single mapping walks and other personal notes of the type "I was there",
but would "allow" the routes of e.g. marathon competitions, long distance
cycling races and routes of motorcar races on the public road network, when
the event is not a one-off. The routes are very visible for some time each time
the event is held; either a line on the ground, fences or other barriers, or
just signposts that get removed later. If we record the data, it _could_ be
reconstructed in the future even if the relation is later destroyed and
eventually deleted, if we don't, it's soon gone forever. The last part
of the draft
sentence above is to say that when a single forest trail connects two villages,
it's probably not a route in the sense of this discussion, but when two or
more trails connectthe same villages but the overwhelming majority of
pedestrians going from A to B use only one of those trails (for whatever
reason), it 'could' be something in the DB; not part of a walking route
network or anything, but not something that should be deleted straight away,
either. If there's a signpost for it at the ends of the route, that's
even better.

-- 
alv

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

Re: [Tagging] barrier enforcing maxwidth

[Lauri Kytömaa]

Colin Smale wrote:
> Regarding maxwidth:physical, the examples in the wiki are actually from
> Finland where they apparently have explicit signs for the physical width.

Just for clarification: even here in Finland the signs are rare, and
the only two
examples I remember straight away on public roads are on reasonably
remote low traffic highways where the carriageway width is otherwise maybe
6 meters (just enough for a lorry and a passenger car to pass each other at
speed and passing places at regular intervals), but at a single point a bridge
is narrower, but wide enough for two oncoming passenger cars to cross the
bridge at the same time. They don't need a sign giving the other direction
priority over the the other, but drivers need to realize they might have to slow
down or even stop if there's oncoming traffic. A fellow mapper here recalled
seeing them on some garage entrances, too.

The signs for physical width might possibly have, just as the signs of
physical free height do have, a number that's rounded down to nearest
10 cm minus 0,1 meters. For height signs that's the supposed margin of
error (to allow for changes in height due to repaving, for some snow on the
ground and on the vehicles, and to leave some air space anyway).

It's probably illegal to ram your vehicle into a too narrow gap on
public roads, even if there are no signs telling the available width. In a
sense maxwidth:legal= (when in addition to maxwidth), when they're
the same, tells the parser that the width is "just" a signposted legal
limit, if a physical maximum isn't present.

Even if the signs usually tell most of the facts, osm data shouldn't be
only about the signs.

-- 
alv

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

Re: [Tagging] Road classification

[Lauri Kytömaa]

Andrew Errington wrote:
> I think that for any particular country, the official classification
> hierarchy should be mapped on to the OSM hierarchy.  If this is not

Countries are different in this regard. For example, here we use the
official classification for all rural state operated roads, and they can
be identified just by which range the road number is in (1-29, 40-98,
and so on). (Being a motorway overrides this "by-number" system.)

However, in that system, "officially" most urban roads are just roads
with numbers over 10 000 (generally not signposted) and
undistinguishable from each other; sometimes the main road
through a city is state operated, sometimes just guideposted as
"route to road #n". So in urban areas, unless the state classification
calls for a higher class, the local mappers have to consider which
roads are "important regional roads" (trunk), "regional road / arterial",
"minor arterial", "collector roads" - the rest are below tertiary. For
each class, there's a list of hints to compare when unsure. It
could, and did in some places take some iterations before some
suburbs had a consistent hierarchy, but the result is added value
from the local contributors.


-- 
alv

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

Re: [Tagging] Buildings mixing residential and commercial use

[Lauri Kytömaa]

On Martin Koppenhoefer wrote:
> I agree. There clearly are typologies with retail (and offices) in the ground 
> floor and residential (or offices) in the upper

IMO an apartment building with shops on the first floor is still an
apartment building. Even the description of building=apartments
mentions "May also have retail outlets on the ground floor".

Even without any additional tags, if there are within the building
nodes or areas with suitable amenity= or shop= tags, we'd already know
some parts of it are used for something else than apartments (even if
smaller office=* may be operating in the apartments). The idea to
further describe the parts or the building is one good way to proceed.

OTOH, if it looks like a shopping center but has some apartments on
the top floor(s), most people would still call the whole a retail
building or supermarket. I doubt there are next to none edge cases
where the classification would vary between mappers.

-- 
alv

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

Re: [Tagging] Describe explicitly that values of highway tag do not imply anything about road quality (except highway=motorway and highway=motorway_link)

[Lauri Kytömaa]

Mateusz Konieczny wrote:
 quality. In area with poor infrastructure road forming main road
 network, of the highest importance in region should be tagged
 highway=trunk - no matter whatever is is high-quality asphalt road or
 unsurfaced tract unusable after major rains.

I generally agree on all the points you mentioned, but I had to
mention two points to this, one on a detail and the second on
what is it that the text should or shouldn't try to convey to the
readers.

1) I'd say that since trunk is the next best thing below
motorway, in any country (or region) there has to be something
between motorway standards and unsurfaced tract unusable
after major rains - primary is a valid long distance road, too. I'm
not even saying a trunk road could't be unpaved, or that it couldn't
be repeatedly blocked sometimes. I did ask on the wiki
highway=trunk tag discussion page in 2009 whether anyone knows
any roads marked as trunk in osm which are unpaved, and only
later read somewhere that south of Sahara most trunk roads are
unpaved, but in that discussion there was no mention of whether
they are (generally) usable after major rains.

I would however be confident enough to assume that no country,
no matter how underprivileged, doesn't have some longer distance
roads that are traversable after and during common adverse
conditions; then if other long distance roads are not equal, they'd
be a step down from that trunk level, even it the better roads do
not cover the whole country. This can, however, possibly, clash
with countries' own osm tagging guidelines if they only use some
administrative class as the base for what is a trunk and what
isn't - I don't know enough details about all the countries. Does
anyone have examples?

2) This gets a little philosophical, because it's about what makes a
road a road. It's somewhat misleading to write that the highway tag
doesn't say _anything_ about the quality, when it's easily read as
doesn't say anything about the physical properties - a road is,
IMO, by definition something that looks like a road and works like
a road (and in western world necessarily also: built as a road), not
any strip of land where somebody once drove through, so it does
describe the limits of what the physical properties can be expected
to be, i.e. the list of worst possible attributes that it needs to fulfill
for people call it a road. At the moment, I don't have a ready
sentence to add, but it's worth noting that the concept of a road
includes both usage and physical appearance.


-- 
alv

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

Re: [Tagging] landcover=trees definition

[Lauri Kytömaa]

Jean-Marc Liotier wrote:
 landuse=residential + natural=grass combination
 instead, but those lawns do not strike me as natural.

The grass is natural (plants), unless it's some sort of man made
plastic artificial grass imitation). The key natural never was only
about geographical features, nor was it only about the untouched
wild natural features; the tagging recommendation change that was
allowed to take place by mistake, i.e. to use natural vs. landuse for
primeval woods vs. in any way managed woods should not be allowed to
creep into the meaning of other things tagged with the natural key.

-- 
alv

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

Re: [Tagging] New Key capacity:*=n values

[Lauri Kytömaa]

johnw wrote:
Access=disabled would be good for this situation, but

In this the disabled is a group, i.e. a mode of transport as the
wiki page calls them, and should be in the key and not in the value;
otherwise some areas would get access=disabled;seniors;pregnant ,
which is awkward.

Also the list of different access tag's values should already be
comprehensive, various user group restrictions are subtypes of the
values that are already described. Some of the values that one can see
in taginfo in use now, could be better described with the
access:conditional= syntax, such as access=dry_weather_only with
access:conditional=yes @ (dry_weather), and many of the values with
some hundreds of uses are plain mistakes, like access=bus (that's
likely
vehicle=no + bus=yes).

-- 
alv

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

Re: [Tagging] New Key capacity:*=n values

[Lauri Kytömaa]

(btw. I don't see any problems with capacity:x=* tags, just the access=* values)

John Willis wrote:
access=customers
Either access=destination or access=permissive, depending on local
laws an practices. (or motor_vehicle=*)

access=emergency
rather access=no + emergency=yes

 a legally separated  group
When it's a group, it belongs in the key, not in the value. There's
two values that are a bit misleading (forestry and agriculture) but
that's because they are used differently, i.e. there are (rare) signs
which effectively mean vehicles allowed only if used for agriculture
and other signs applying to vehicles registered as agricultural
vehicles (not allowed, i.e. tractors and, possibly, other motorized
machinery).

-- 
alv

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

Re: [Tagging] tagging large intersections cross-road sections

[Lauri Kytömaa]

Florian Lohoff wrote:
 On Wed, Jun 24, 2015 at 10:51:08AM +0200, Tom Pfeifer wrote:
 Do we have better alternatives? Should we leave the snippet sections unnamed?

 I'd love routing people to speak up - I'd prefer to not name them and
 tag them according to be a crossing link.

Three points here:
I thought the originally linked video said that they already detect and deal
with the short sections within intersections and they only tell the correct,
final, road name. So the problem in this discussion has already been
solved, for most cases(?) anyway.

The other point is that the data model probably just doesn't fit all cases, but
it should be possible to derive the correct instructions in either case. The
name of the software escapes me now, (or was it Traveling salesman?) but
years back there was already a solution which, when it was building the
local routing database, detected dual/separated carriageway roads, i.e.
which two highway ways were in fact describing a single road. It sounds
easy but there were some edge cases etc., as far as I know.

But, given that knowledge, it's possible for the routing directions algorithm
to detect that the name of the crossing road changes in that intersection,
and then ignore the short inter-intersection way's name tag when spelling
out the instructions. It can't universally ignore short named sections,
because the distances between carriageways can be longer than some
single carriageway T-junctions really close to each other.

And, lastly, although not designed for this, there's a not yet so commonly
used tag, or combination of two tags, that implicitly tell us the section is
(at least in part) within an intersection: (as far as I know stopping/halting
in intersections isn't allowed in any countries?)

parking:lane:both=no_stopping (i.e. no halting on either side)
parking:condition:reason=junction (i.e. the no halting rule here is not from
explicit traffic signs, but the intersection rule - it can't be reliably derived
from present data, if one wants to e.g. make a map)

-- 
alv

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

Re: [Tagging] Removal of amenity from OSM tagging

[Lauri Kytömaa]

pmailkeey wrote:
 johnw wrote:
 Forest=natural ?
 isn’t that natural=wood?
 I don't know the difference between a wood and a forest!

landuse=forest and natural=wood are a poor example for historical
reasons, when some thought that natural=wood together with
landuse=forest was redundant, when it's not: an area used for
forestry can be without tree cover (after a full chop it takes
anything from years to decades before the newly planted trees look and
function like a wood/forest, yet the usage of the land is still
growing wood for timber). That's why the keys of the tags are
different, so that one can tag both/all of them. We can live with the
tags as they are used and documented now, but they shouldn't be used
as a good example for future tagging. There are no man made trees in
the forest, they all grow naturally.


In osm a single way or node can be different things to different
consumers. If one is interested in the usage of the land, they look at
the landuse key, if they're interested in what natural features occupy
the area, they look at the natural key; sometimes there's an implied,
mostly undocumented relation between the two and sometimes the other
key is omitted.

There can not be a strict choice between is this one or the other,
but mappers can describe only those aspects they see and care about.
Data consumers, interested in something which they care about, can
consider the probabilities of other related tags implying yet unstated
features: for example, many places of worship already entered in osm
coincide with the buildings they occupy, but people have only tagged
amenity=place_of_worship. Given a pile of stones or pieces of timber
stuck together, only human interpretation makes it a building, but we
also give those piles other meanings; pub, shop, address, ruins. Just
tag all and every meaning that make sense for that way or node.

-- 
alv

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

Re: [Tagging] housenumber on node and area

[Lauri Kytömaa]

On Wed, May 27, 2015 at 11:38 AM, Markus Lindholm
markus.lindh...@gmail.com wrote:
 Otherwise they make bad routing targets

Complete addresses may indeed be unique, but the housenumber part
can be and is in may countries the same for, for example all
apartments in an apartment building. In other countries each apartment
may have a running housenumber, i.e. unique within that street.

Effectively, all software working with osm data has to support (i.e.
build an index of) nodes and ways with addr:* tags, no matter whether
they are a part of a way or a relation, or whether they stand alone.
In most cases, if not in all use cases, the different properties and
objects it might refer to can then be algorithmically extracted; if
that is absolutely necessary. Hence, I would say that address info on
a node is never wrong; it accomplishes the goals and every application
can find it, but IF the address is the only address of some thing
(being an entrance or a building), it's better to have it on the node
or the way depicting that feature. When a feature has several
addresses, the most simple solution is again a node for each address;
everybody can extract and use all those addresses.

-- 
alv

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

Re: [Tagging] Airport power and USB stations

[Lauri Kytömaa]

AYTOUN RALPH wrote:
 Then the next thing they will need to know is the type of socket so type=*
 (example ... plug_UK ; plug_EU ; USB123 ; USB_C)

It is customary in osm to avoid type=*, except for relations. Type of
what, i.e. power_socket=* or socket=plug_UK (or, rather, the better
values somebody else linked to).

-- 
alv

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

Re: [Tagging] AE and BE orthography in tagging

[Lauri Kytömaa]

 Martin Koppenhoefer wrote:
 - railway=subway - not sure why this was chosen, underground seems a
 reasonable BE candidate while the metro term seems to be Paris-related in

If my memory serves me right, I've read an ancient (in OSM context)
discussion about it: most subway/underground/metro systems contain
sections that are not underground, so with two possible terms, the one
which doesn't give the impression that the whole track system must be
underground was chosen.

-- 
alv

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

[Tagging] new highway tag for small and informal footpaths; trail

[Lauri Kytömaa]

Martin Koppenhoefer wrote:

(given that footway, cycleway and bridleway are all synonyms of
highway=path designated=foo, dedicated=foo, official=foo, etc.).


Ralf Kleineisel wrote:

Footway on the other hand is for designated pedestrian ways,
i.e. in many countries a blue sign with pedestrians on it.


No, not that restrictive. When path was introduced, the equivalence
was given inother direction: there are globally lots of ways tagged
as footways and cycleways that have no signposts at all, some of
which were even drawn before anyone had ever visioned highway=path.

Changing the definition of highway=footway etc. has never even been
proposed - it's unnecessary wordplay to claim retrospectively that
the word designated in highway=footway definition was originally
used for the same as the value designated for access tags. Yet
some translated guidelines have taken that view. Any highway=path
+ foot=designated is for practical purposes equal to a
highway=footway - there's a way for walking (unless it has other
access tags, but a footway could have them, too.)

--
Alv

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

[Tagging] new highway tag for small and informal footpaths; trail

[Lauri Kytömaa]

Ralf Kleineisel wrote:

The wiki says:
The example photos there support this.


And the other pages say otherwise. As you say, example photos, not
definition photos.

The text and the pictures in the wiki have been changed to each and
every direction so many times that none will be able to force their
view on all pages - and even more so to check that all use cases in
the database comply with that changed form. The status quo is to keep
the mixed and varying definitions scattered on lots of pages and
try to live with that. All attempts have stopped at people stating
the facts and their opinions of how things should be and shouldn't be
- and often with uncompatible constraints.

And sadly no one noticed soon enough after the path was introduced,
that the documentation for the equivalence was written in the wrong
direction. So some took it for granted that they were only
ways-with-blue-signs, others kept using the style they were since the
beginning. Given any mapped footway/cycleway, you can not know if it
has a blue sign (or a local equivalent).

All these arguments, and various common interpretations are listed at

http://wiki.openstreetmap.org/wiki/Consolidation_footway_cycleway_path

The section Current situation lists why it's impossible to claim
that footway or cycleway is anyhow clearly defined to be limited to
(with the blue signs) signposted ways. It also in a way lists what
the interpretations have in common.

Redefining tag meanings only in the wiki will never work, as somebody
would have to inspect, for example, all the 1.3 million ways already
tagged with footway.


The word designated says that there is a sign, doesn't it?


That is only one meaning of the word, and requiring a sign wasn't the
way footway/cycleway were used before path. If a way is legal (or
even possible, think narrow urban stuff) only for pedestrians,
setting up or omitting any signs (not forbidding pedestrians,
naturally) doesn't make it anything else than a footway. Likewise ways
with a no motor vehicles sign are often cycleways - only pedestrians
and cyclists are allowed and do use them, even if a different sign
would imply otherwise a bit different traffic rules on those ways.


--
Alv

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

[Tagging] [OSM-talk] Tagging Scheme Recommendations: highway=path, footway, trail?

[Lauri Kytömaa]

It's not detailled enough. A path is too narrow for a 4
wheels vehicle like a car but not for a 2 wheels vehicle
like a moped or a motorbike (or no


While that is often true, the criteria goes the other way:
- if the way is too narrow to fit a car (hey, my summer
  car is only 1.48 m wide) or a tractor, it can't be a
  highway=track, but is a footway, bridleway, cycleway
  or a path
- not all paths are too narrow for four wheel vehicles;
  many of the things some country guidelines recommend
  to tag as highway=path + bicycle=designated etc. are
  3 to 5 meters wide.
Given a random ... linear thing you cross in the forest,
without any knowledge of the restrictions possibly posted
at the ends, you can be sure it's anything from path to
bridleway if it's not wide enough; but not the other way.

Replies should go to the tagging list.

--
Alv

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