Re: [Tagging] highway=residential_link

[Paul Johnson]

On Wed, Nov 11, 2015 at 4:46 AM, Martin Koppenhoefer  wrote:

>
> 2015-11-11 11:00 GMT+01:00 Gerd Petermann  >:
>
>> pro 2) : less confusing for those who like the duck test
>> (if there is a tertiary_link there should also be a xyz_link)
>> contra 2): more work for many people, hard to verify
>> reg. 2b)
>>
>
>
> I believe even tertiary links should be extremely rare. The roads
> typically having links are motorways, trunks and many of the primaries
> (depending on the region), some of the secondaries, rarely tertiaries (if
> ever, might also be seen as classification errors but who knows, maybe
> there is good reason in some areas for these).
>

So, how do you propose the very common situation of porkchops on tertiaries
be handled?  One such example is at 1st and Norfolk in Tulsa:
http://www.openstreetmap.org/?mlat=36.15860=-95.97860#map=19/36.15860/-95.97860
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] highway=residential_link

[Gerd Petermann]

yes, a missing name should be no reason for a highway=residential_link.

During the last days I've reviewed the remaining highway=residential_link
roads, a few of them are quite special, so I fully understand that mappers
have the idea that residential might not be correct, esp. when they
believe that a residential road requires buildings close to it, which in my 
eyes 
is also not mandantory.

So, I see two possibilities:
1) change the wiki(s) and validators to make absolutely clear that
the _link suffix should not be used with other than the major roads which are 
now
documented or
2a) change the wiki(s) to tolerate suffix _link for all types of minor ways
(also footway, service etc) with the advice to use them 
for 
- roads that split at junctions
- shortcuts before junctions
(both with pictures)
- maybe more  ?
without forcing this suffix for those roads.
2b) tell data consumers, QA tools etc. to treat the roads
similar to those without the suffix.

pro 1): easy to do
contra 1): many users will not care about what is written in a wiki, so
edit wars are possible

pro 2) : less confusing for those who like the duck test 
(if there is a tertiary_link there should also be a xyz_link)
contra 2): more work for many people, hard to verify 
reg. 2b)

So, my proposal:
Let's do 1) and I'll try to keep an eye on Taginfo to 
warn mappers when they use the _link suffix for 
a minor road as long as we don't implement some kind
of automatism for that.

Gerd


Von: Michał Brzozowski 
Gesendet: Mittwoch, 11. November 2015 10:21
An: Tag discussion, strategy and related tools
Betreff: Re: [Tagging] highway=residential_link

On Tue, Nov 10, 2015 at 9:50 PM, Joachim  wrote:
>  Using no link gives many warning in QA tools. Using
> highway=residential plus noname=yes might be a workaround in the
> current situation.

This is not the only example when a residential road doesn't have a
name. Keep in mind this is specifically why addr:place was invented -
there are villages (in quite a few countries around Europe, for
instance) when streets have no names, yet they are still residential.
The QA software you use makes wrong assumptions.

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] Proposal: effective_hours tag for restrictions

[Paul Johnson]

On Wed, Nov 11, 2015 at 4:26 AM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> I like the idea to use effective_hours=*.
>
> I just wonder if this oneway="Fr-Su 00:-24:00"
>
> means something like that:
>
> https://www.openstreetmap.org/way/28865357
>

Yes, though I would assume he means oneway=yes@Fr-Su in this case.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] amenity=bicycle_repair_station

[Paul Johnson]

On Tue, Nov 10, 2015 at 9:25 AM, Martin Koppenhoefer  wrote:

>
> 2015-11-10 13:31 GMT+01:00 moltonel 3x Combo :
>
>> >> I like amenity=bicycle_tool_stand,
>> >
>> > +1, "repair_station" is ambigous / can easily be misunderstood. Even
>> though
>> > "amenity=self_serve_bicycle_tool_stand" looks like an overkill on first
>> > sight, it is even more verbose and less likely to be misunderstood.
>>
>> 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
> similarly ambiguous.
>

"Bicycle repair station" appears to be the common English name for this
kind of thing.  Here's what I got from various Google queries:

*Tool station* yields that this is literally the trademark of a specific
chain of tool stores in the UK.  Nope!
*Tool stand* gives results similar to "bicycle repair station", but with
metal/wood shop workbenches instead.  This is not what we intend, either.
*Bicycle tool stand* yields at-home/in-shop floor repair stands, close but
no cigar.
*Bicycle repair station* yields an image search sample of several popular
designs of the object in question.  This would suggest that we have a user
education problem, not a phraseology problem.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Martin Koppenhoefer]

sent from a phone

> Am 11.11.2015 um 08:20 schrieb Paul Johnson :
> 
> I thought the problem was a 2000 member limitation in the API, though the 
> geographic grouping really helps manageability anyway even if the network 
> doesn't change at the jurisdiction line


making the relations smaller also helps to reduce conflicts 


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

Re: [Tagging] Proposal: effective_hours tag for restrictions

[Gerd Petermann]

I like the idea to use effective_hours=*.

I just wonder if this oneway="Fr-Su 00:-24:00"

means something like that:

https://www.openstreetmap.org/way/28865357


I'll ask the mapper, as it may also be a typo for opening_hours, though

I doubt that.


I assume there is a oneway sign with an additional sign meaning

something like "Friday to Sunday", so I guess we should also

allow

oneway=yes

effective_hours="Fr-Su 00:00-24:00"


Gerd



Von: Paul Johnson 
Gesendet: Mittwoch, 11. November 2015 11:06
An: osm
Cc: Tag discussion, strategy and related tools
Betreff: [Tagging] Proposal: effective_hours tag for restrictions

On Tue, Nov 10, 2015 at 7:36 AM, Nicolás Alvarez 
> wrote:

El 10 nov 2015, a las 09:57, Badita Florin 
> escribió:

Hello, i have a question, how do you tag the opening hours for a turn 
restriction that is activated only during a certain time of day or week.
Also, do you have an idea what software is using this attributies ?

http://i.imgur.com/a1eBFoe.jpg

On the wiki the information is old and also deprecated

http://wiki.openstreetmap.org/wiki/Relation:restriction

It says about hour_on but on the wiki the tag is not valid.

http://wiki.openstreetmap.org/wiki/Key:hour_on

Should i use the http://wiki.openstreetmap.org/wiki/Key:opening_hours tag, as 
recomented ?

My fear is that i will add a restriction, and all of the apps that does not 
parse the opening hours will use this as a default , and will make this 
restriction permanent, producing maybe more damage then not adding the 
restriction at all

I don't know what the correct tag is, and the wiki is inconsistent about it. It 
says hour_on is deprecated in favor of opening_hours and conditional 
restrictions, but the Conditional restrictions page says nothing about turn 
restrictions, and the turn restrictions page says you should use hour_on...

I interpreted that as the format is identical to opening_hours=*, but it's 
implied that there's a different tag for effective hours, without mentioning 
what that tag is.  Indeed hour_on=*, et. al. were deprecated as being ambiguous 
for all but the simplest use cases (which is also why opening_hours=* was 
created for POIs).  I'd be willing to go with effective_hours=*, using the same 
format as opening_hours=* if that sounds alright, and update the relevant pages 
as appropriate.  The hours in question would represent the the time frame in 
which the restriction applies.

For example, 36th and Harvard in Tulsa:  
http://www.mapillary.com/map/im/thEPKkBiTOgqG3GwEoUieA/photo
The sign reads "No left turn Mon-Sat 7AM-7PM".

type=restriction
restriction=no_left_turn
effective_hours=Mo-Sa 07:00-19:00

A more complex example can be found at 11th and Denver: 
http://www.mapillary.com/map/im/iSaY1yIcDNfkt8lCfeaoOA/photo  The sign reads 
"no left turn 7:30-8:30AM, 4:15-5:30PM except MTTA busses".

type=restriction
restriction=no_left_turn
effective_hours=7:30-8:30,16:15-17:30
except=bus
except:operator=Metropolitan Tulsa Transit Authority

Granted, this is a weird one, since I'm not clear if this would be a boolean OR 
or AND situation, AND would be what it is, but it might be interpreted as OR 
(ie, any MTTA vehicle, OR any bus; rather than "any bus operated by MTTA").  
We're also leaving out that while they're technically not supposed to, MTTA 
maintenance vehicles, MTTA tow trucks and MTTA supervisors also make the left 
turn there without so much as a second glance from the traffic cops (arguably 
it's better to get the busses moving again faster than make nonrevenue vehicles 
associated with the agency go around and keep traffic on Denver flowing, so 
dinging these guys on a technicality would go against the spirit of the law).

But as far as I know there is no OSM routing engine that supports conditional 
restrictions yet, whatever the tag. It's not an easy problem, especially since 
the algorithm has to consider if the restriction applies at the time the user 
would arrive to that point, rather than at the time he asks for the route at 
the beginning of the trip.

Probably because if the editors can't figure it out, the consumers aren't going 
to, either.  That said, this is a tagging issue first and foremost, and I 
believe effective_hours=* would be an elegant solution.  Thoughts?
___
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] Proposal: Sunset ref=* on ways in favor of relations

[Martin Koppenhoefer]

sent from a phone

> Am 11.11.2015 um 08:48 schrieb Paul Johnson :
> 
> Where I have run into issues that make it difficult to tell if the relation 
> is correct is when a route ends on a dual carriageway on one or both ends 
> with at least one central segment being a two-way single carriageway.  In 
> this case, the simplest fix seems to be to create a super-relation, and then 
> add a child relation for each direction with a role of a cardinal direction, 
> and have all the ways in the child directions have a role of forward or 
> backward as appropriate, and tag the relation direction=west, for example 
> (this is already how Interstates, which are, AFAICT, always fully divided).


+1, this is also done for bus routes for instance 


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

Re: [Tagging] highway=residential_link

[Tom Pfeifer]

Marco Antonio wrote on 2015-11-11 02:10:

On Tue, Nov 10, 2015 at 12:19 PM, Mateusz Konieczny
 wrote:

Can you provide an example of real situation where
highway=residential_link makes sense?


In my city (in South America) it is very common to have this type of roads

https://www.openstreetmap.org/way/253086441
https://www.openstreetmap.org/way/223240901
https://www.openstreetmap.org/way/223240900
https://www.openstreetmap.org/way/230640681
https://www.openstreetmap.org/way/239951395
https://www.openstreetmap.org/way/358563357
https://www.openstreetmap.org/way/358563356
https://www.openstreetmap.org/way/202716638
https://www.openstreetmap.org/way/319956454
https://www.openstreetmap.org/way/230640660

This ways connect two residential roads, do not have names, and have a
direction. maybe some roads appear the prolongation of roads but no.



https://www.openstreetmap.org/way/253086441
https://www.openstreetmap.org/way/223240901
https://www.openstreetmap.org/way/223240900
look like residential roads to me, having a name or not.
Not even the construction style separates them from the
named residentails.

https://www.openstreetmap.org/way/223240898
https://www.openstreetmap.org/way/253086443
are not necessary to split off the longer section, since
they have exactly the same attributes. This is unnecessay
fragmentation of ways.

The dual carriageway
https://www.openstreetmap.org/way/253086428
is tagged residential. I would expect it to have some priority,
e.g. right-of-way against the smaller roads, in which case it
should be tagged highway=tertiary.

Finally I wonder if the single-building hospital
https://www.openstreetmap.org/node/2590640017
should be a clinic ?

tom


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

Re: [Tagging] highway=residential_link

[Martin Koppenhoefer]

2015-11-11 11:00 GMT+01:00 Gerd Petermann :

> pro 2) : less confusing for those who like the duck test
> (if there is a tertiary_link there should also be a xyz_link)
> contra 2): more work for many people, hard to verify
> reg. 2b)
>


I believe even tertiary links should be extremely rare. The roads typically
having links are motorways, trunks and many of the primaries (depending on
the region), some of the secondaries, rarely tertiaries (if ever, might
also be seen as classification errors but who knows, maybe there is good
reason in some areas for these).

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

Re: [Tagging] highway=residential_link

[Martin Koppenhoefer]

2015-11-11 11:57 GMT+01:00 Paul Johnson :

> So, how do you propose the very common situation of porkchops on
> tertiaries be handled?  One such example is at 1st and Norfolk in Tulsa:
> http://www.openstreetmap.org/?mlat=36.15860=-95.97860#map=19/36.15860/-95.97860
>
>


these could be tagged highway=residential (in this case, as they're part of
South Norfolk Avenue which is residential according to osm). What do you
gain by calling them tertiary_link?

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

Re: [Tagging] amenity=bicycle_repair_station

[Erik Johansson]

amenity=diy_tool_station
bicycle=yes
iceskates=yes
locked=yes
opening_hours=during games.

I only know of one for iceskates though, can I can't remember why it
wasn't made a generic tag, the current tag is  a bit like
subway_entrance vs entrance.




On Tue, Nov 10, 2015 at 3:41 AM, Bryce Nesbitt  wrote:
> amenity=bicycle_repair_station has a problem: it's attracting lots of active
> tagging
> of shops offering bicycle repair.  For example:
> http://www.openstreetmap.org/node/3772809894
> and http://www.openstreetmap.org/way/337421757
>
>
> That was not the intent.  amenity=bicycle_repair_station was meant for
> unattended
> tool stands, often outdoors, often 24/7, generally public.
>
> I'm seeking support for a mechanical edit to a new tag name.
> There are known automated clients of this tag, and I am in contact with
> both.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>



-- 
/emj

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

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Colin Smale]

 

I would assume that there are many, many more consumers than
producers... 

--colin 

On 2015-11-11 17:27, Richard Welty wrote: 

> On 11/11/15 9:51 AM, David Earl wrote: 
> 
>> On Wed, 11 Nov 2015 at 14:01 Richard Welty > > wrote:
>> 
>> it's an inevitable consequence of serializing a complex data
>> structure.
>> we either find ways to deal with it or else we accept limits on what
>> we can accomplish.
>> 
>> Or we change the way we do it.
>> 
>> For example, emitting the relations first would help somewhat.
> this simply replaces energy expended in the consumer with energy
> expended in the producer. this is not necessarily bad, but it is a
> significant architectural design decision.
> 
> richard 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Motorway link no default oneway

[Joachim]

I can understand your concern, but please have a look at the reactions when
the proposal still included "don't route over motorway_link without
oneway". The reactions said there is no chance in enforcing this.

https://lists.openstreetmap.org/pipermail/tagging/2015-September/026453.html

2015-10-30 0:51 GMT+01:00 André Pirard :

> On 2015-10-29 20:45, Joachim wrote :
>
It says:
>
> Strongly recommend explicit tagging of oneway=* on highway=motorway_link.
>
> For routing purposes no recommendation for ways with *undefined oneway*
> is made. A provider should decide on it's own considering the documentation
> history and current data.
>
> It is totally unacceptable to let a GPS provider "decide on its (not it's)
> own" (what?) based on fuzzy and vague "documentation history and current
> data".  OSM is the place that *must* contain the data to be used and,
> should the oneway status be undetermined, routing must obviously be
> *requested* to not let the cars go through that place.
> If that undetermined status existed, contributors should not be
> recommended but requested explicit tagging.
> And hence, quality assurance providers should be *requested* to check
> motorway_link statuses and to warn the culprit and not an innocent as
> Osmose does, and even this Tagging list in such grave security cases.
>
> Please let us not make OSM responsible for car crashes.
>
> Cheers
>
> 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] Proposal: Sunset ref=* on ways in favor of relations

[Paul Johnson]

On Wed, Nov 11, 2015 at 6:48 AM, David Earl 
wrote:

> Having been negative, now the opposite...
>
> Why stop at ref?
>
> There are lots of places where it would help to group things uniquely
> rather than by a simple text string. Names are the obvious next one. If we
> put the names on a separate shared object, you can then tell when they are
> actually the same street, or whatever, rather than just a coincidence.
> There are two entirely separate Love Lane in Cambridge, for example, and
> many High Street all over the place. How do you know they are the same,
> especially if they don't all interconnect, or conversely they do, but are
> actually different.
>

Associated street relations
 do this, but
it appears there's a big of a micromapping curve to it.


> Also you could deal with the case of things which have different names
> rather than the bodges we have at present. For example, where a street has
> different names on opposites sides which are rare, but do exist. Or where
> you have a part of a street known by the name of its terrace of houses on
> one section, but where the street is really continuous. Or a bridge has its
> own name but the street with a name continues across it. And that's even
> without starting on different languages.
>
> Which then begs the question: why not do all or most of the tags this way?
> Share tags between multiple objects as a matter of course when those
> objects collectively represent one thing. And different but overlapping
> subsets of objects represent different things. Then maybe say if we're
> doing it this way some of the time, why not do it all of the time, even for
> single objects, just for consistency.
>

The reason I've singled out automobile routes specifically on this has been
that mapping this on ways instead of relations are inconsistent with how
other routes are presently handled (that is, with relations) and
maintaining this information in this weird one-off exception is a
maintainability nightmare that just isn't present with relations.
Relations do present their own challenges, however, with road routes, these
are relatively easy to edit and validate (compared to, say, bus routes
(which, seemingly increasingly as available funding diminishes, tend to
have a lot of repeat members which make setting the order very difficult)
or administrative boundaries).


> In which case, are relations just in the picture because they happen to
> provide a crude mechanism for this which already exists?
>

I would argue that ways and routes are separate entities for which it is
exceedingly rare to find a 1:1 congruence (go ahead and try finding a
single member route=road relation for which there are no changes in lane
patterns including turn lanes, turn restrictions, bridges, tunnels, or any
other objects that would cause a way to be split, and therefore ref=* on
relations is a crude mechanism for which we now have an elegant solution
available.

I can only think of one example of a route that has just one member
offhand, and that's relation 3632355
, OK 34B.  It connects US
283 to the unincorporated village of Brinkman, OK in Greer County, and the
highway itself is very likely to be decommissioned in the current round of
budget cuts or around the time OklaDOT gets a pothole report and wonders
why it's still in the state inventory.  The town's bank closed in 1927 and
half the town burned down in 1929, with the town disincorporated not long
after.  The school (which at one point had 450 students enrolled) closed in
1965, and the post office closed 5 years later, and the railroad stopped
serving the location in 1972.  Judging by the two dwellings and lack of
vehicles in aerial photography, I would hazard to guess that the village is
within a rounding error of 0 population today.  Almost any route in
literally almost anywhere more relevant than Brinkman is very likely to
have a route comprising of more than one way.  I'm aware of other possible
one-member routes, however, these are all in similarly dead-since-the-1930s
western Oklahoma/Kansas locations that are unlikely to stay in state
inventory once OklaDOT or KDOT realizes that it's control points for it
haven't had any significant population, if any permanent population at all,
in roughly 80 years.

If all tags were done this way might we get to a point where we are
> representing real world objects as a whole rather than trying to infer it
> from groups of tags which happen to be similar and are split up purely for
> convenience of managing other things like bus routes or bridges which run
> along part of the real object.


I'm not clear what you're getting at here, but if I'm reading that right
(and I don't honestly believe I am), you're objecting to relations as a
data type, because the whole of a complex object/site/route/whatever can be
inferred from other entities?  If 

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Paul Johnson]

On Wed, Nov 11, 2015 at 3:19 AM, Martin Koppenhoefer  wrote:

>
>
> sent from a phone
>
> > Am 11.11.2015 um 08:20 schrieb Paul Johnson :
> >
> > I thought the problem was a 2000 member limitation in the API, though
> the geographic grouping really helps manageability anyway even if the
> network doesn't change at the jurisdiction line
>
>
> making the relations smaller also helps to reduce conflicts


Yeah, for urban areas, I'm considering splitting these at the county lines
to help reduce that potential, particularly with routes traversing Tulsa,
Oklahoma, Canadian, Cleveland and Wagoner counties.  I'm going to examine
that situation more closely once I'm done with detail mapping lane counts,
turn lanes, destinations and junction refs on Interstate 40.  This will
 give me a good idea of what to expect for major midwestern freeways in
terms of how many splits one can reasonably expect on a highly detailed
long-distance freeway in a single largely rural state.  I fully expect this
will be almost certainly necessary for I 5 and US 101 in California as
well, regardless of the results I get here, due to the sheer scale of those
routes (101 is 808.111 mi; 5 is 796.432 mi and both involve some of the
most populous and dense urban centers in the US at multiple locations along
their routes).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[David Earl]

On Wed, 11 Nov 2015 at 14:01 Richard Welty  wrote:

> it's an inevitable consequence of serializing a complex data structure.
> we either find ways to deal with it or else we accept limits on what
> we can accomplish.
>

Or we change the way we do it.

For example, emitting the relations first would help somewhat.

Maybe thinking about the structure further rather than using relations
because they are there.

Or make it easier to cope by providing much easier and less resource hungry
means of managing this

and/or a higher level api which abstracts some of the change and provides a
better level of backward compatibility, at least for extending time. So for
example "tell me what the road number(s) of this way are" irrespective of
how they are stored, and "is this way the same as that one in respect of
road number X"? and so on.

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

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[David Earl]

I can see the attraction of this, but I do always worry about gross lack of
backward compatibility being a huge barrier to adoption. If you have to
scramble to keep up with changes like this whenever they happen, you aren't
going to be keen to be a consumer of OSM data when it's only peripheral to
what you're trying to do. I hear all the arguments about being able to move
forward and so on, but if you can't keep the customers, there's no point.

Also relations are a massively bigger burden on a consumer. Every time you
get one you've got to do a look up in a potentially HUGE mass of other
data, so it probably has to be done via a database rather than in memory.
Getting the information you need becomes orders of magnitude slower for
every object.

It also doesn't help that relations appear last in the OSM data, so you
can't even note the relations as you go and then look them up as you see
ways etc. You have to process the lot first and then go back and to the
original task. Again it pretty much mandates a huge database for anything
other than a small area.

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

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Paul Johnson]

On Wed, Nov 11, 2015 at 3:22 AM, Martin Koppenhoefer  wrote:

>
>
> sent from a phone
>
> > Am 11.11.2015 um 08:48 schrieb Paul Johnson :
> >
> > Where I have run into issues that make it difficult to tell if the
> relation is correct is when a route ends on a dual carriageway on one or
> both ends with at least one central segment being a two-way single
> carriageway.  In this case, the simplest fix seems to be to create a
> super-relation, and then add a child relation for each direction with a
> role of a cardinal direction, and have all the ways in the child directions
> have a role of forward or backward as appropriate, and tag the relation
> direction=west, for example (this is already how Interstates, which are,
> AFAICT, always fully divided).
>
>
> +1, this is also done for bus routes for instance
>

Pet peeve with this, though I expect this will be alleviated with time,
people tagging east/west as roles on *ways* instead of child relations.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Richard Welty]

On 11/11/15 9:51 AM, David Earl wrote:
>
>
> On Wed, 11 Nov 2015 at 14:01 Richard Welty  > wrote:
>
> it's an inevitable consequence of serializing a complex data
> structure.
> we either find ways to deal with it or else we accept limits on what
> we can accomplish.
>
>
> Or we change the way we do it.
>
> For example, emitting the relations first would help somewhat.
this simply replaces energy expended in the consumer with energy
expended in the producer. this is not necessarily bad, but it is a
significant architectural design decision.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




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

[Tagging] Proposal: effective_hours tag for restrictions

[Paul Johnson]

On Tue, Nov 10, 2015 at 7:36 AM, Nicolás Alvarez 
wrote:

>
> El 10 nov 2015, a las 09:57, Badita Florin 
> escribió:
>
> Hello, i have a question, how do you tag the opening hours for a turn
> restriction that is activated only during a certain time of day or week.
> Also, do you have an idea what software is using this attributies ?
>
> http://i.imgur.com/a1eBFoe.jpg
>
> On the wiki the information is old and also deprecated
>
> http://wiki.openstreetmap.org/wiki/Relation:restriction
>
> It says about hour_on but on the wiki the tag is not valid.
>
> http://wiki.openstreetmap.org/wiki/Key:hour_on
>
> Should i use the http://wiki.openstreetmap.org/wiki/Key:opening_hours
> tag, as recomented ?
>
> My fear is that i will add a restriction, and all of the apps that does
> not parse the opening hours will use this as a default , and will make this
> restriction permanent, producing maybe more damage then not adding the
> restriction at all
>
>
> I don't know what the correct tag is, and the wiki is inconsistent about
> it. It says hour_on is deprecated in favor of opening_hours and conditional
> restrictions, but the Conditional restrictions page says nothing about turn
> restrictions, and the turn restrictions page says you should use hour_on...
>

I interpreted that as the format is identical to opening_hours=*, but it's
implied that there's a different tag for effective hours, without
mentioning what that tag is.  Indeed hour_on=*, *et. al.* were deprecated
as being ambiguous for all but the simplest use cases (which is also why
opening_hours=* was created for POIs).  I'd be willing to go with
effective_hours=*, using the same format as opening_hours=* if that sounds
alright, and update the relevant pages as appropriate.  The hours in
question would represent the the time frame in which the restriction
applies.

For example, 36th and Harvard in Tulsa:
http://www.mapillary.com/map/im/thEPKkBiTOgqG3GwEoUieA/photo
The sign reads "No left turn Mon-Sat 7AM-7PM".

type=restriction
restriction=no_left_turn
effective_hours=Mo-Sa 07:00-19:00

A more complex example can be found at 11th and Denver:
http://www.mapillary.com/map/im/iSaY1yIcDNfkt8lCfeaoOA/photo  The sign
reads "no left turn 7:30-8:30AM, 4:15-5:30PM except MTTA busses".

type=restriction
restriction=no_left_turn
effective_hours=7:30-8:30,16:15-17:30
except=bus
except:operator=Metropolitan Tulsa Transit Authority

Granted, this is a weird one, since I'm not clear if this would be a
boolean OR or AND situation, AND would be what it is, but it might be
interpreted as OR (ie, any MTTA vehicle, OR any bus; rather than "any bus
operated by MTTA").  We're also leaving out that while they're technically
not supposed to, MTTA maintenance vehicles, MTTA tow trucks and MTTA
supervisors also make the left turn there without so much as a second
glance from the traffic cops (arguably it's better to get the busses moving
again faster than make nonrevenue vehicles associated with the agency go
around and keep traffic on Denver flowing, so dinging these guys on a
technicality would go against the spirit of the law).


> But as far as I know there is no OSM routing engine that supports
> conditional restrictions yet, whatever the tag. It's not an easy problem,
> especially since the algorithm has to consider if the restriction applies
> at the time the user would arrive to that point, rather than at the time he
> asks for the route at the beginning of the trip.
>

Probably because if the editors can't figure it out, the consumers aren't
going to, either.  That said, this is a tagging issue first and foremost,
and I believe effective_hours=* would be an elegant solution.  Thoughts?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[David Earl]

Having been negative, now the opposite...

Why stop at ref?

There are lots of places where it would help to group things uniquely
rather than by a simple text string. Names are the obvious next one. If we
put the names on a separate shared object, you can then tell when they are
actually the same street, or whatever, rather than just a coincidence.
There are two entirely separate Love Lane in Cambridge, for example, and
many High Street all over the place. How do you know they are the same,
especially if they don't all interconnect, or conversely they do, but are
actually different.

Also you could deal with the case of things which have different names
rather than the bodges we have at present. For example, where a street has
different names on opposites sides which are rare, but do exist. Or where
you have a part of a street known by the name of its terrace of houses on
one section, but where the street is really continuous. Or a bridge has its
own name but the street with a name continues across it. And that's even
without starting on different languages.

Which then begs the question: why not do all or most of the tags this way?
Share tags between multiple objects as a matter of course when those
objects collectively represent one thing. And different but overlapping
subsets of objects represent different things. Then maybe say if we're
doing it this way some of the time, why not do it all of the time, even for
single objects, just for consistency.

In which case, are relations just in the picture because they happen to
provide a crude mechanism for this which already exists? If all tags were
done this way might we get to a point where we are representing real world
objects as a whole rather than trying to infer it from groups of tags which
happen to be similar and are split up purely for convenience of managing
other things like bus routes or bridges which run along part of the real
object.

David

On Wed, 11 Nov 2015 at 12:37 David Earl  wrote:

> I can see the attraction of this, but I do always worry about gross lack
> of backward compatibility being a huge barrier to adoption. If you have to
> scramble to keep up with changes like this whenever they happen, you aren't
> going to be keen to be a consumer of OSM data when it's only peripheral to
> what you're trying to do. I hear all the arguments about being able to move
> forward and so on, but if you can't keep the customers, there's no point.
>
> Also relations are a massively bigger burden on a consumer. Every time you
> get one you've got to do a look up in a potentially HUGE mass of other
> data, so it probably has to be done via a database rather than in memory.
> Getting the information you need becomes orders of magnitude slower for
> every object.
>
> It also doesn't help that relations appear last in the OSM data, so you
> can't even note the relations as you go and then look them up as you see
> ways etc. You have to process the lot first and then go back and to the
> original task. Again it pretty much mandates a huge database for anything
> other than a small area.
>
> David
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging dangerous intersections

[Paul Johnson]

On Tue, Nov 10, 2015 at 3:24 AM, Kieron Thwaites 
wrote:

> Hi,
>
> I recently passed through an intersection in a particularly dodgy part
> of town that actually had warning signs up, warning motorists that
> said intersection is a hotspot for "smash and grab" robberies.  (If
> anyone is interested, it's on Google Streetview too:
> https://goo.gl/maps/kYkdMR9Kmpk)
>

Not getting into the ethics (I've got a pretty strong moral objection to
navigation for literally avoiding social issues) or legal issues (Microsoft
holds a patent on it) of an "avoid ghetto" feature, one could potentially
work out a traffic_sign=* tag for this feature to indicate the location of
such signs.


> I'd like to add this information to OSM -- certainly, it could be used
> by routing software to avoid the area unless there was no other
> sensible alternative.  However, I'm not sure how best to tag it.  The
> only thing that I've found is the proposed "hazard" tag
> (http://wiki.openstreetmap.org/wiki/Proposed_features/hazard), but as
> it seems to be in a permanent draft state (since 2009), I'm not sure
> if this is the best solution.
>
> Are there better, more current ways of tagging things like these, or
> is the proposed "hazard" tag the best option?
>
> (As an aside: if we go with the "hazard" tag, perhaps some work on
> completing the proposal and getting it approved would be a good idea.
> taginfo shows a few thousand usages to date.)
>

I'd be more inclined to use a hazard=* type tag to indicate locations that
have signs up indicating a tangible and consistent threat, such as might be
the case with intersections marked with a "High Collision Intersection"
sign or "Fatality" sign frequently found in British Columbia or "Dangerous
Intersection" found in Oregon, or the white crosses indicating where people
have died in a traffic accident on Montana's state highways (though in that
case, it might be more appropriate to tag them as roadside crosses instead
or additionally).  Such information could potentially used to alert the
user to the situation as well (for example, Osmand could say something like
"Attention, dangerous intersection" or "Attention, dangerous curve" or
something to that nature).

As an aside, there is already standardized treatments for such situations
in the MUTCD in both the US and Canada that already have tagging available,
such as traffic_calming=rumble_strip, or however one might tag optical
speed bars
,
which I've seen on several highways in the mountain west on downhill lanes.
Whether or not this actually gets employed by the DOT seems to be a
regional consideration, with notable outliers being BC's nonstandard
signage that speak specifically to the hazard on one end of the spectrum,
and the Texas/Oklahoma/Kansas tendency to be very by the book in using
rumble strips in conjunction with standard signage like "Sharp Curve Ahead"
at the end of a long straightaway, "Signal Ahead", "Stop Ahead" and
"Reduced Speed Ahead" signage at problem locations.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Richard Welty]

On 11/11/15 7:37 AM, David Earl wrote:
> I can see the attraction of this, but I do always worry about gross
> lack of backward compatibility being a huge barrier to adoption. If
> you have to scramble to keep up with changes like this whenever they
> happen, you aren't going to be keen to be a consumer of OSM data when
> it's only peripheral to what you're trying to do. I hear all the
> arguments about being able to move forward and so on, but if you can't
> keep the customers, there's no point.
>
> Also relations are a massively bigger burden on a consumer. Every time
> you get one you've got to do a look up in a potentially HUGE mass of
> other data, so it probably has to be done via a database rather than
> in memory. Getting the information you need becomes orders of
> magnitude slower for every object.
>
it's an inevitable consequence of serializing a complex data structure.
we either find ways to deal with it or else we accept limits on what
we can accomplish.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




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

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Marc Gemis]

On Wed, Nov 11, 2015 at 1:48 PM, David Earl 
wrote:

> There are lots of places where it would help to group things uniquely
> rather than by a simple text string. Names are the obvious next one. If we
> put the names on a separate shared object, you can then tell when they are
> actually the same street, or whatever, rather than just a coincidence.
> There are two entirely separate Love Lane in Cambridge, for example, and
> many High Street all over the place. How do you know they are the same,
> especially if they don't all interconnect, or conversely they do, but are
> actually different.
>

There are already relations for that, a street-relation [1] or
associatedStreet-relation [2]. There was a huge discussion all over OSM
earlier this year about the benefits/drawback of such a relation. Or was it
last year ? Similar arguments: too difficult to deal with, simple data
consumers would no longer see the address. On the other hand, the
consistency like you point out.

regards

m

[1] http://wiki.openstreetmap.org/wiki/Relation:street
[2] http://wiki.openstreetmap.org/wiki/Relation:associatedStreet
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Richard Welty]

On 11/11/15 12:01 PM, Colin Smale wrote:
>
>   
>
> I would assume that there are many, many more consumers than producers...
>
>
in terms of distinct applications, yes. in terms of network connections,
there is
a 1-to-1 relationship. the work is the same, it's a question of
placement at the
back end or the front end.

and while there is a bit of work involved, it's not huge (unless the
consumer is
asking for a lot of data). i wrote code for my ghost tracks leaflet
widget to convert
the results of an overpass query into displayable GeoJSON, so i'm at
least a little
familiar with the work we're discussing. it's not that hard a piece of
code to write.

so there are also two kinds of work here - the work to write the code,
which many
are able to do (and copies of it are around to crib from) and the actual
conversion
work during the operation of the app/consumer/whatever the scale of which is
directly related to the volume of data being processed.

and if we try to push that work back into the server, we run some risks
in terms
of overloading the servers, not because one instance is a lot of work
but because
a lot of simultaneous instances can be a lot of work.

like i say this is a serious architectural decision, not to be made lightly.

so is the objection writing the code, or the placement of the work? we
can provide
libraries for developers of data consumers, if the former is the issue.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




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

Re: [Tagging] highway=residential_link

[Mateusz Konieczny]

On Tue, 10 Nov 2015 21:50:41 +0100
Joachim  wrote:

> Many see _link only as slip roads. But using it for at-grade junctions
> like described in the wiki has one advantage: _link is usually tagged
> without a name because it connects two named roads and has none
> itself. Using no link gives many warning in QA tools. Using
> highway=residential plus noname=yes might be a workaround in the
> current situation.

False positive in QA tool is not a good reason to force everybody to
handle residential_link, service_link etc


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

Re: [Tagging] highway=residential_link

[Colin Smale]

 

The fact that tools don't currently support something is no reason to
oppose its introduction either. If it were, we would never be able to
change anything. 

On 2015-11-11 21:26, Mateusz Konieczny wrote: 

> On Tue, 10 Nov 2015 21:50:41 +0100
> Joachim  wrote:
> 
>> Many see _link only as slip roads. But using it for at-grade junctions
>> like described in the wiki has one advantage: _link is usually tagged
>> without a name because it connects two named roads and has none
>> itself. Using no link gives many warning in QA tools. Using
>> highway=residential plus noname=yes might be a workaround in the
>> current situation.
> 
> False positive in QA tool is not a good reason to force everybody to
> handle residential_link, service_link etc
> 
> ___
> 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] highway=residential_link

[Mateusz Konieczny]

On Wed, 11 Nov 2015 21:36:22 +0100
Colin Smale  wrote:
 
> On 2015-11-11 21:26, Mateusz Konieczny wrote: 
> 
> > On Tue, 10 Nov 2015 21:50:41 +0100
> > Joachim  wrote:
> > 
> >> Many see _link only as slip roads. But using it for at-grade
> >> junctions like described in the wiki has one advantage: _link is
> >> usually tagged without a name because it connects two named roads
> >> and has none itself. Using no link gives many warning in QA tools.
> >> Using highway=residential plus noname=yes might be a workaround in
> >> the current situation.
> > 
> > False positive in QA tool is not a good reason to force everybody to
> > handle residential_link, service_link etc
> > 
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>  
> The fact that tools don't currently support something is no reason to
> oppose its introduction either. If it were, we would never be able to
> change anything. 

Note that I am not claiming that "tools don't currently support
something" as reason to oppose introduction something.

I was claiming that false positive in a QA tool is not a good reason to
break nearly all existing data consumers using road network data.

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

Re: [Tagging] highway=residential_link

[John Willis]

> On Nov 11, 2015, at 6:21 PM, Michał Brzozowski  wrote:
> 
> This is not the only example when a residential road doesn't have a
> name

There are no residential street names in all of Japan for tertiary roads and 
below (99.99%). There are a lot of numbered roads, but usually the web of 
residential that springs from them is unlabeled. 

So in some places, a named residential road (even an informal name) is the 
exception, not the rule. 

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

Re: [Tagging] highway=residential_link

[Mateusz Konieczny]

On Tue, 10 Nov 2015 18:45:29 +0100
Colin Smale  wrote:

>  
> 
> No, I can't think of any real examples at the moment, but that doesn't
> make them any less existable. And if they exist, then
> highway=residential_link is more logical than forcing
> highway=residential and adding link=yes or some other flag to
> distinguish them. 
> 
> On 2015-11-10 17:19, Mateusz Konieczny wrote: 
> 
> > On Tue, 10 Nov 2015 13:54:45 +0100
> > Colin Smale  wrote:
> > 
> >> Duck test: short link between two primaries is primary_link, so a
> >> short link between two residentials is residential_link. The fact
> >> that it is a very rare scenario does not detract from the fact that
> >> it is existable. Why resort to a different tagging pattern if it
> >> fits in the one we use for other analogous situations?
> > 
> > I encountered many short links between highway=residential, every
> > single one was clear highway=residential.
> > 
> > For example see
> > http://www.openstreetmap.org/way/24789911#map=17/50.06036/19.92942
> > 
> > Can you provide an example of real situation where
> > highway=residential_link makes sense?
>  

For me expecting everybody to start handling residential_link is for
worse than link=yes.

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

Re: [Tagging] highway=residential_link

[Mateusz Konieczny]

On Wed, 11 Nov 2015 10:00:41 +
Gerd Petermann  wrote:

> yes, a missing name should be no reason for a
> highway=residential_link.
> 
> During the last days I've reviewed the remaining
> highway=residential_link roads, a few of them are quite special, so I
> fully understand that mappers have the idea that residential might
> not be correct, esp. when they believe that a residential road
> requires buildings close to it, which in my eyes is also not
> mandantory.
> 
> So, I see two possibilities:
> 1) change the wiki(s) and validators to make absolutely clear that
> the _link suffix should not be used with other than the major roads
> which are now documented or
> 2a) change the wiki(s) to tolerate suffix _link for all types of
> minor ways (also footway, service etc) with the advice to use them 
> for 
> - roads that split at junctions
> - shortcuts before junctions
> (both with pictures)
> - maybe more  ?
> without forcing this suffix for those roads.
> 2b) tell data consumers, QA tools etc. to treat the roads
> similar to those without the suffix.
> 
> pro 1): easy to do
> contra 1): many users will not care about what is written in a wiki,
> so edit wars are possible
> 
> pro 2) : less confusing for those who like the duck test 
> (if there is a tertiary_link there should also be a xyz_link)
> contra 2): more work for many people, hard to verify 
> reg. 2b)
> 
> So, my proposal:
> Let's do 1) and I'll try to keep an eye on Taginfo to 
> warn mappers when they use the _link suffix for 
> a minor road as long as we don't implement some kind
> of automatism for that.
> 
> Gerd
> 
> 
> Von: Michał Brzozowski 
> Gesendet: Mittwoch, 11. November 2015 10:21
> An: Tag discussion, strategy and related tools
> Betreff: Re: [Tagging] highway=residential_link
> 
> On Tue, Nov 10, 2015 at 9:50 PM, Joachim  wrote:
> >  Using no link gives many warning in QA tools. Using
> > highway=residential plus noname=yes might be a workaround in the
> > current situation.
> 
> This is not the only example when a residential road doesn't have a
> name. Keep in mind this is specifically why addr:place was invented -
> there are villages (in quite a few countries around Europe, for
> instance) when streets have no names, yet they are still residential.
> The QA software you use makes wrong assumptions.
> 
> Michał

The big problem with 2a is that breaks nearly all data consumers of
road network data and increases tagging complexity without noticeable
benefits.

It reminds me about
https://github.com/gravitystorm/openstreetmap-carto/issues/230#issuecomment-29238913

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

Re: [Tagging] amenity=bicycle_repair_station

[Warin]

On 12/11/2015 12:46 AM, Erik Johansson wrote:

amenity=diy_tool_station
bicycle=yes
iceskates=yes
locked=yes
opening_hours=during games.

I only know of one for iceskates though, can I can't remember why it
wasn't made a generic tag, the current tag is  a bit like
subway_entrance vs entrance.


That looks to be much better .. as it can be applied to anything, skateboards 
for instance.

Possibly sports sub tag could be used instead of tagging each activity/item.

Though the opening_hours ... should be in 'free text' mode .. thus 
opening_hours="during games"







On Tue, Nov 10, 2015 at 3:41 AM, Bryce Nesbitt  wrote:

amenity=bicycle_repair_station has a problem: it's attracting lots of active
tagging
of shops offering bicycle repair.  For example:
http://www.openstreetmap.org/node/3772809894
and http://www.openstreetmap.org/way/337421757


That was not the intent.  amenity=bicycle_repair_station was meant for
unattended
tool stands, often outdoors, often 24/7, generally public.

I'm seeking support for a mechanical edit to a new tag name.
There are known automated clients of this tag, and I am in contact with
both.

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







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