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

[Martin Koppenhoefer]

2015-11-16 7:39 GMT+01:00 Martin Koppenhoefer :

> you can ask the api for a specific version, sth like
> api06.osm.org/relation/rel-number/rel-version
>


the correct link is (example for version 1 of rel 123):
http://www.openstreetmap.org/api/0.6/relation/123/1

cheers,
Martin
___
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 15.11.2015 um 20:13 schrieb Joachim :
> 
> What other chances are there to retrieve older
> versions of relations other than JOSM/osm.org? I read something about
> overpass.


you can ask the api for a specific version, sth like 
api06.osm.org/relation/rel-number/rel-version

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

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

[Joachim]

In my practice I use relations for every route, but leave ref on the
ways for signed routes. For roads these are motorway and
"Bundesstraßen" (mostly primary) in Germany.
While checking e-roads in Germany I came across a relation which was
empty. Viewing the history failed because of a timeout from the API
(history too large). Luckily the ways still had int_ref so restoring
the relation was easy. What other chances are there to retrieve older
versions of relations other than JOSM/osm.org? I read something about
overpass.

Regards Joachim

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

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

[Paul Norman]

On 11/10/2015 11:20 PM, Paul Johnson wrote:

I thought the problem was a 2000 member limitation in the API


This is on nodes per way, not members per relation. There are 164 larger 
relations.


Even if there is no hard limit, I'd consider a 2k member relation past 
the limit of what is practical to work with.


___
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 Thu, Nov 12, 2015 at 1:47 AM, Marc Gemis  wrote:

>
> 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.
>

I see associatedStreet as a nicer solution for dealing with organizing
objects relevant to the right of way itself, but feel it's kind of a reach
to try to have it replace the Karlsruhe convention for addressing.
___
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] 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 that's the case, inference from

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] 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

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

[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

[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

[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

[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] 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

[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] 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: Sunset ref=* on ways in favor of relations

[Paul Johnson]

On Sun, Nov 8, 2015 at 5:24 PM, Dave Swarthout 
wrote:

>
> On Mon, Nov 9, 2015 at 5:39 AM, moltonel 3x Combo 
> wrote:
>
>> While I agree that relations can break and can be tricky to edit, I
>> find it tiring to see this argument repeatedly used against the use of
>> relations for this or that usecase.
>>
>
> Your point is well taken. You've heard the last on this topic from me. I
> suppose in some way my arguments are an attempt to raise awareness of the
> limitations of the tools we use to work with relations not with the use of
> relations, which are certainly necessary to deal with complex mapping
> situations.
>

Though it's one of those chicken/egg problems.  Something's got to make the
first move.  I really believe bringing road routes onto the same scheme as
every other route used in OSM is about the only real way to break the
deadlock with the toolchain on this and get some creative juices flowing on
how to make relations less of the red-headed stepchild people are making it
out to be.  We ran into the same issue and overcame it with turn
restrictions already...now it's almost exceedingly difficult to break one
of these relations in JOSM.

Granted, I've seen folks also bring up the difficulties with administrative
boundaries, however, that type of relation has it's own unique set of
issues editing that are largely not in play with routes.  Additionally,
road routes tend to be the simplest flavor of route, since it's just an
ordered list where each member way only appears one time:  Very editor and
validator friendly already.

I have run into the conflict situation a few times when working with very
long routes crossing more frequently edited areas, however, this conflict
is usually pretty obvious and easy to resolve with a sort and check for
continuity.

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).

But, you do get a lot of advantages from relations for this, such as being
able to quickly and easily pull from API an entire network of highways, a
single highway, or even just a section where it shares with another route,
in a relatively sane and easy way.
___
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 Sat, Nov 7, 2015 at 10:47 PM, Richard Welty 
wrote:

> On 11/7/15 6:02 PM, Martin Koppenhoefer wrote:
> >
> > sent from a phone
> >
> >> Am 07.11.2015 um 22:31 schrieb Richard Fairhurst  >:
> >>
> >> To do it properly and
> >> lessen the chance of multiple relations being accidentally created for
> the
> >> same route (as continues to happen with NCN routes in the UK and
> elsewhere),
> >> it will need either a new API search method or a dependency on Overpass.
> >
> > Are multiple relations for (pieces of) the same route really a big
> problem? We could have multiple relations until they meet and then merge
> them.
> >
> >
> for the very long Interstate and US highways, in the US we usually
> create a super relation and then have per-state relations. otherwise
> you get into relations that you can barely if at all load into an editor.
>

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 (ie, I 44 is still I 44 when it
runs into Missouri, as opposed to OK 325 which turns into NM 456 when it
crosses the Dry Cimmaron River at the border).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Dave Swarthout]

On Mon, Nov 9, 2015 at 5:39 AM, moltonel 3x Combo 
wrote:

> While I agree that relations can break and can be tricky to edit, I
> find it tiring to see this argument repeatedly used against the use of
> relations for this or that usecase.
>

Your point is well taken. You've heard the last on this topic from me. I
suppose in some way my arguments are an attempt to raise awareness of the
limitations of the tools we use to work with relations not with the use of
relations, which are certainly necessary to deal with complex mapping
situations.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[moltonel 3x Combo]

On 08/11/2015, Dave Swarthout  wrote:
> In that section the author, sk53, says, "Creating a whole set of boundaries
> encompassing one country and part of another is not a light undertaking on
> OSM. It is fiddly work, and involves manipulating objects with many
> dependencies. In practice I find it somewhat reminiscent of software
> migration projects: mainly mundane but you need to keep your wits about
> you.
>
> Contrary to what some believe, none of the OSM editors can prevent damage
> to other objects in this process. Mapping boundaries on this scale
> inevitably involves relations, and relations are not semantically clean
> objects at the level of the OSM data model."

While I agree that relations can break and can be tricky to edit, I
find it tiring to see this argument repeatedly used against the use of
relations for this or that usecase.

The stuff we map is becoming more complex and, in increasingly many
cases, relations are the best available tool for the job. Why complain
about the difficulty of editin boundary,multipolygons,or routes
relations when maping the same features without relations would be
even worse ?

There are some grey areas: when do I switch from a shared-nodes closed
way to a multipolygon (or from ref tag on ways to a relation), but
we're lucky enough to have options. Let each maper decide wich
technique makes the best use of his (an furture contributors's) time.

Sure, It'd be great to have proper Area (and maybe even Multiline)
elements in the OSM data model to replace hacky uses of the Relation
element. Or even "just" have the API check uploaded relations for
geometrical correctness. But don't wait for that to start using
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/8/15 5:00 AM, Dave Swarthout wrote:
> Sorry to keep working this side topic but I want to add this
> information FYI. I just came across this interesting article that
> talks about the difficulty of editing relations in JOSM. Even though
> we're talking about routes in this thread I think it's still relevant
> to our recent discussions:
>
> http://sk53-osm.blogspot.com/2015/10/irish-vice-counties-creation-of.html
> ; and especially the section headed "Technical Aspects (OSM)". 
>
> In that section the author, sk53, says, "Creating a whole set of
> boundaries encompassing one country and part of another is not a light
> undertaking on OSM. It is fiddly work, and involves manipulating
> objects with many dependencies. In practice I find it somewhat
> reminiscent of software migration projects: mainly mundane but you
> need to keep your wits about you.
>
> Contrary to what some believe, none of the OSM editors can prevent
> damage to other objects in this process. Mapping boundaries on this
> scale inevitably involves relations, and relations are not
> semantically clean objects at the level of the OSM data model."
>
> I certainly agree with that assessment.
>
i have done a lot of work with admin boundaries in upstate NY and i find it
critical to have a well planned workflow when handling this situation.
otherwise
there are lots of things that are easy to forget.

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

[Colin Smale]

 

Surely the fact that it is difficult to get it 100% perfect should not
stop us from moving at all? As with all "big" problems, a
divide-and-conquer strategy often helps to make things achievable which
at first glance seem insurmountable. 

As this functionality really should be built into each and every editor,
we need a mechanism to make sure that all editors implement the same
rules. To me, that means documenting something in a way which
distinguishes between right/good and wrong/bad, which is often thought
to be against the laissez-faire nature of OSM because it limits the
freedom and creativity of mappers. Getting that balancing act right is a
difficult challenge. 

//colin 

On 2015-11-08 13:33, Andy Townsend wrote: 

> On 07/11/2015 23:02, Martin Koppenhoefer wrote: 
> 
>> Are multiple relations for (pieces of) the same route really a big problem? 
>> We could have multiple relations until they meet and then merge them.
> 
> The problem isn't that we can't merge multiple relations later, it's that we 
> can't stop them being created in the first place.  Also "we can merge" might 
> need a survey to resolve differing tag issues, as the the knowledge of "how 
> to merge relations" and "what it's actually like on the ground" will likely 
> be in different people.
> 
> Cheers,
> 
> Andy (SomeoneElse)
> 
> ___
> 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

[Andy Townsend]

On 07/11/2015 23:02, Martin Koppenhoefer wrote:


Are multiple relations for (pieces of) the same route really a big problem? We 
could have multiple relations until they meet and then merge them.



The problem isn't that we can't merge multiple relations later, it's 
that we can't stop them being created in the first place.  Also "we can 
merge" might need a survey to resolve differing tag issues, as the the 
knowledge of "how to merge relations" and "what it's actually like on 
the ground" will likely be in different people.


Cheers,

Andy (SomeoneElse)



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

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

[Dave Swarthout]

Sorry to keep working this side topic but I want to add this information
FYI. I just came across this interesting article that talks about the
difficulty of editing relations in JOSM. Even though we're talking about
routes in this thread I think it's still relevant to our recent discussions:

http://sk53-osm.blogspot.com/2015/10/irish-vice-counties-creation-of.html ;
and especially the section headed "Technical Aspects (OSM)".

In that section the author, sk53, says, "Creating a whole set of boundaries
encompassing one country and part of another is not a light undertaking on
OSM. It is fiddly work, and involves manipulating objects with many
dependencies. In practice I find it somewhat reminiscent of software
migration projects: mainly mundane but you need to keep your wits about you.

Contrary to what some believe, none of the OSM editors can prevent damage
to other objects in this process. Mapping boundaries on this scale
inevitably involves relations, and relations are not semantically clean
objects at the level of the OSM data model."

I certainly agree with that assessment.

Cheers,
Dave

On Sun, Nov 8, 2015 at 1:55 PM, Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > Am 08.11.2015 um 05:47 schrieb Richard Welty :
> >
> > otherwise
> > you get into relations that you can barely if at all load into an editor.
>
>
> +1, also the risk of a conflict on upload is higher for big relations
>
>
> cheers
> Martin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>



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

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

[Martin Koppenhoefer]

sent from a phone

> Am 08.11.2015 um 05:47 schrieb Richard Welty :
> 
> otherwise
> you get into relations that you can barely if at all load into an editor.


+1, also the risk of a conflict on upload is higher for big relations


cheers 
Martin

___
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/7/15 6:02 PM, Martin Koppenhoefer wrote:
>
> sent from a phone
>
>> Am 07.11.2015 um 22:31 schrieb Richard Fairhurst :
>>
>> To do it properly and
>> lessen the chance of multiple relations being accidentally created for the
>> same route (as continues to happen with NCN routes in the UK and elsewhere),
>> it will need either a new API search method or a dependency on Overpass.
>
> Are multiple relations for (pieces of) the same route really a big problem? 
> We could have multiple relations until they meet and then merge them.
>
>
for the very long Interstate and US highways, in the US we usually
create a super relation and then have per-state relations. otherwise
you get into relations that you can barely if at all load into an editor.

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

[Martin Koppenhoefer]

sent from a phone

> Am 07.11.2015 um 22:31 schrieb Richard Fairhurst :
> 
> To do it properly and
> lessen the chance of multiple relations being accidentally created for the
> same route (as continues to happen with NCN routes in the UK and elsewhere),
> it will need either a new API search method or a dependency on Overpass.


Are multiple relations for (pieces of) the same route really a big problem? We 
could have multiple relations until they meet and then merge them.

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

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

[Richard Fairhurst]

Paul Johnson wrote:
> You're blaming the community for a software issue here, and that's a 
> little unfair to the community.  If iD or potlatch or whatever are that 
> broken, then fucking fix iD and Potlatch.

Firstly, you are not helping your cause by being so gratuitously offensive,
though I regret to say that prior experience makes this no surprise to me.

Secondly, you underestimate the effort required. To do it properly and
lessen the chance of multiple relations being accidentally created for the
same route (as continues to happen with NCN routes in the UK and elsewhere),
it will need either a new API search method or a dependency on Overpass.
Adding a dependency to a third-party service is not (in my view) appropriate
for a core editor hosted on osm.org.

With that in mind, I look forward to your work "fix"ing things rather than
simply using the mailing lists to offensively demand that others do your
bidding.

Richard




--
View this message in context: 
http://gis.19327.n5.nabble.com/Proposal-Sunset-ref-on-ways-in-favor-of-relations-tp5859233p5859372.html
Sent from the Tagging mailing list archive at Nabble.com.

___
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 Sat, Nov 7, 2015 at 6:49 AM, Dave Swarthout 
wrote:

> >OK, well, in JOSM at least, using the Relation Toolbox is snappy simple
>
> You cannot be serious, Paul. There is a relation here in Thailand, a
> super-relation?, that I've been wanting to edit for months. It has three or
> four relations, provincial, 2 wood multipolygons, and a river) sharing ways
> along an international boundary. Trying to separate one of those wood
> multipolygons (so it can be split into smaller chunks) from the rest is
> something that will take hours for me to do. It's so tricky, even with the
> powerful Relation Toolbox, that I've simply ignored it because there's too
> much other work over here that has a higher priority.
>

Except we're talking about like objects in the route relations case, not
badly designed multipolygons of gargantuan size.  Your situation would have
been a mess anyway even without relations if all of those objects were
sharing a common way.
___
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 Sat, Nov 7, 2015 at 7:17 AM, Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > Am 07.11.2015 um 13:49 schrieb Dave Swarthout :
> >
> > . It has three or four relations, provincial, 2 wood multipolygons, and
> a river) sharing ways along an international boundary. Trying to separate
> one of those wood multipolygons (so it can be split into smaller chunks)
> from the rest is something that will take hours for me to do. It's so
> tricky, even with the powerful Relation Toolbox, that I've simply ignored
> it because there's too much other work over here that has a higher priority.
>
>
> having a river (waterway =river) and a forest share the same way is
> generally broken (as the forest is a area and the river is a centerline).
> This kind of mapping is initially faster at the expense of more
> difficulties later on for modifications
>

I'm going to have to agree here.  You can't blame relations for making
stupid editing decision before you got there.  You can, however, go back
and ask that person to back out of that edit or work to resolve the issue.
___
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 07.11.2015 um 13:49 schrieb Dave Swarthout :
> 
> . It has three or four relations, provincial, 2 wood multipolygons, and a 
> river) sharing ways along an international boundary. Trying to separate one 
> of those wood multipolygons (so it can be split into smaller chunks) from the 
> rest is something that will take hours for me to do. It's so tricky, even 
> with the powerful Relation Toolbox, that I've simply ignored it because 
> there's too much other work over here that has a higher priority. 


having a river (waterway =river) and a forest share the same way is generally 
broken (as the forest is a area and the river is a centerline). This kind of 
mapping is initially faster at the expense of more difficulties later on for 
modifications.

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

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

[Dave Swarthout]

>OK, well, in JOSM at least, using the Relation Toolbox is snappy simple

You cannot be serious, Paul. There is a relation here in Thailand, a
super-relation?, that I've been wanting to edit for months. It has three or
four relations, provincial, 2 wood multipolygons, and a river) sharing ways
along an international boundary. Trying to separate one of those wood
multipolygons (so it can be split into smaller chunks) from the rest is
something that will take hours for me to do. It's so tricky, even with the
powerful Relation Toolbox, that I've simply ignored it because there's too
much other work over here that has a higher priority.

I don't want to continue this discussion ad nauseum because this list isn't
the place for it. We'll have to agree to disagree and just move on. Someday
when I have plenty of time maybe I'll try making some suggestions to the
people that develop tools for JOSM.

On Sat, Nov 7, 2015 at 7:24 PM, Michael Reichert  wrote:

> Hi,
>
> Am 2015-11-06 um 11:24 schrieb Paul Johnson:
> > […]
> > *The fix: * I propose a goal of December 31, 2016 to eliminate ref=* as a
> > method to describe an overlying route; this should be more than ample
> time
> > for existing data consumers to catch up on doing a move and ensure data
> > consistency for routes.  Kill the dinosaur:
> >
> >- Deprecate ref=* on ways from having anything to do with the routes
> >they run over, use relations instead and phase out the use of
> >route-describing refs on ways (be it removal of the tag or
> replacement of
> >the key's value with a ref that actually applies to the way instead
> of the
> >route).
>
> I strongly oppose this.
>
> Usings relations for something which can be expressed using tags on ways
> is usually a bad idea.
>
> (1) Data users have to parse relations (i.e. need more processing time
> and memory). Currently you only have to import ways (and nodes are used
> to build the geometry if you convert OSM data into OGC simple features)
> into your data structure (e.g. a PostGIS database) if you want to get
> all road segments of German motorway "A 1". You just have to query the
> ref column (maybe use LIKE opeator or something similar because A 1 and
> A 61 share some road segments).
>
> (2) Mappers have to work with relations. This makes editing OSM data
> more difficult. We shold keep editing easy and the entrance hurdle as
> low as possible. Mappers (and developers, too) are the most important
> and most valueable resource at OSM.
>
> (3) Relations break easily. We already have enough work to get all those
> multipolygons repaired which are broken by newbies (and experienced)
> mappers not to mention all those public transport relations which have
> been broken sometimes for months or years.
>
> >- Stop rendering this key and instead render the relations in
> opencarto
> >and other featured layers.
>
> Which key is rendered and which not, is decided by those people spending
> days and weeks of time into OSM Carto. They usually decide which tags
> they render and which not by looking which tags are in use and which not.
>
> I think that we will still use ref=* over route relations at OSM in the
> next two years.
>
> Best regards
>
> Michael
>
>
> --
> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
> ausgenommen)
> I prefer GPG encryption of emails. (does not apply on mailing lists)
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>


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

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

[Michael Reichert]

Hi,

Am 2015-11-06 um 11:24 schrieb Paul Johnson:
> […]
> *The fix: * I propose a goal of December 31, 2016 to eliminate ref=* as a
> method to describe an overlying route; this should be more than ample time
> for existing data consumers to catch up on doing a move and ensure data
> consistency for routes.  Kill the dinosaur:
> 
>- Deprecate ref=* on ways from having anything to do with the routes
>they run over, use relations instead and phase out the use of
>route-describing refs on ways (be it removal of the tag or replacement of
>the key's value with a ref that actually applies to the way instead of the
>route).

I strongly oppose this.

Usings relations for something which can be expressed using tags on ways
is usually a bad idea.

(1) Data users have to parse relations (i.e. need more processing time
and memory). Currently you only have to import ways (and nodes are used
to build the geometry if you convert OSM data into OGC simple features)
into your data structure (e.g. a PostGIS database) if you want to get
all road segments of German motorway "A 1". You just have to query the
ref column (maybe use LIKE opeator or something similar because A 1 and
A 61 share some road segments).

(2) Mappers have to work with relations. This makes editing OSM data
more difficult. We shold keep editing easy and the entrance hurdle as
low as possible. Mappers (and developers, too) are the most important
and most valueable resource at OSM.

(3) Relations break easily. We already have enough work to get all those
multipolygons repaired which are broken by newbies (and experienced)
mappers not to mention all those public transport relations which have
been broken sometimes for months or years.

>- Stop rendering this key and instead render the relations in opencarto
>and other featured layers.

Which key is rendered and which not, is decided by those people spending
days and weeks of time into OSM Carto. They usually decide which tags
they render and which not by looking which tags are in use and which not.

I think that we will still use ref=* over route relations at OSM in the
next two years.

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)




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

[Paul Johnson]

On Sat, Nov 7, 2015 at 6:03 AM, Paul Johnson  wrote:

> On Fri, Nov 6, 2015 at 5:36 PM, Dave Swarthout 
> wrote:
>
>> @Colin - I see it now in Wiktionary, but since it is not in the OSM Wiki
>> how would renderers show or use that information? I guess my point is that
>> the relation manager and tools are difficult to master and forcing their
>> use on the general mapping community would be a mistake. Even if
>> deprecating the ref tag was deemed okay by our little group, the general
>> user community will resist the change and rightly so IMO
>>
>
> You're blaming the community for a software issue here, and that's a
> little unfair to the community.  If iD or potlatch or whatever are that
> broken, then fucking fix iD and Potlatch.  There's zero reason relations
> should be harder to use than nodes and ways.  If it is, then the software
> is Doing It Wrong.
>

Sorry for going all Linus Torvalds there, but seriously, the tools
shouldn't be a barrier to moving things to a more consistent level of
maintainability.
___
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 Fri, Nov 6, 2015 at 5:36 PM, Dave Swarthout 
wrote:

> @Colin - I see it now in Wiktionary, but since it is not in the OSM Wiki
> how would renderers show or use that information? I guess my point is that
> the relation manager and tools are difficult to master and forcing their
> use on the general mapping community would be a mistake. Even if
> deprecating the ref tag was deemed okay by our little group, the general
> user community will resist the change and rightly so IMO
>

You're blaming the community for a software issue here, and that's a little
unfair to the community.  If iD or potlatch or whatever are that broken,
then fucking fix iD and Potlatch.  There's zero reason relations should be
harder to use than nodes and ways.  If it is, then the software is Doing It
Wrong.
___
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 Fri, Nov 6, 2015 at 12:56 PM, David Marchal  wrote:

> ___
> >
> > On 06/11/2015 10:24, Paul Johnson wrote:
> >
> > Obviously in places where a road can have multiple equivalent
> > references (such as the US) route relations perfect sense (as does
> > figuring out which routes are actually signed on which bits of road)
> > but in places where there's only one real ref per piece of tarmac (such
> > as the UK) there's no need to force mappers to start maintaining
> > relations as well as just recording the reference.
>
> I also agrees with Paul. This proposal can be useful in some situations,
> but not all networks are such a mess. Here, in France, apart from E-roads,,
> there are virtually no road with several refs, and, AFAIK, that's the same
> for nearby countries. Besides, maintaining such a long relation can quickly
> become a nightmare, so I don't think it would really be useful in most
> situations, even if I understand it could be useful in some situations,
> like the USA networks you described.


Toby's solution of favoring the relations over the way value of ref=* would
cover this.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Dave Swarthout]

@Colin - I see it now in Wiktionary, but since it is not in the OSM Wiki
how would renderers show or use that information? I guess my point is that
the relation manager and tools are difficult to master and forcing their
use on the general mapping community would be a mistake. Even if
deprecating the ref tag was deemed okay by our little group, the general
user community will resist the change and rightly so IMO

Dave

On Fri, Nov 6, 2015 at 8:46 PM, Colin Smale  wrote:

>
>
>
>
>
> On 2015-11-06 14:26, Dave Swarthout wrote:
>
> I was looking at a what I surmise to be a ferry route earlier today and it
> had a tag of route=fairway. Did the mapper not realize what he was doing or
> are the diagnostic tools for determining errors in relations not that
> robust?
>
>
>
> Are you sure that route=fairway is wrong? It can have a nautical meaning:
>
> https://en.wiktionary.org/wiki/fairway
>
> //colin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>


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

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

[Richard Welty]

On 11/6/15 5:01 PM, Paul Johnson  wrote:

> > Stop rendering this key and instead render the relations

>> >
>> > Is there *any* map style that does this at the moment?
>> >
> I believe Toby had a working mapnik-based renderer doing this on osm.us at
> one point, though i'm not sure what became of this.
>
it was never on osm.us so far as i know. the demo is still up here:

http://bl.ocks.org/ToeBee/raw/6119134/#13/42.6276/-73.8955

Phil Gold did a lot of work on this, but he's been busy with other things
and i haven't heard of any work on this in a while. i got a lot of the NYS
county route shields up and running.

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

[David Marchal]

___
> 
> On 06/11/2015 10:24, Paul Johnson wrote: 
> 
> Obviously in places where a road can have multiple equivalent 
> references (such as the US) route relations perfect sense (as does 
> figuring out which routes are actually signed on which bits of road) 
> but in places where there's only one real ref per piece of tarmac (such 
> as the UK) there's no need to force mappers to start maintaining 
> relations as well as just recording the reference. 

I also agrees with Paul. This proposal can be useful in some situations, but 
not all networks are such a mess. Here, in France, apart from E-roads,, there 
are virtually no road with several refs, and, AFAIK, that's the same for nearby 
countries. Besides, maintaining such a long relation can quickly become a 
nightmare, so I don't think it would really be useful in most situations, even 
if I understand it could be useful in some situations, like the USA networks 
you described.   
___
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 06.11.2015 um 14:00 schrieb Christoph Hormann :
> 
> AFAIK osm2pgsql does not support including relation membership info in 
> the rendering database.


it can make objects from multipoligon and route relations 

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

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

[Andrew MacKinnon]

This seems reasonable.

It would be helpful if we changed the renderers to render the ref in a
route=road relation and ignore the ref tag if a route=road relation is
present. In Canada we had a problem a while ago with a user making
mechanical edits adding prefixes like "ON" and "RR" to a lot of roads.
I have been gradually deleting these prefixes but it is very time
consuming. Relations are a much better way of storing this data and if
renderers use the relation instead, then I could just delete these ref
tags instead of fixing them.

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

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

[Craig Wallace]

On 2015-11-06 13:44, Paul Johnson wrote:

On Fri, Nov 6, 2015 at 7:02 AM, Andy Townsend mailto:ajt1...@gmail.com>> wrote:

Obviously in places where a road can have multiple equivalent
references (such as the US) route relations perfect sense (as does
figuring out which routes are actually signed on which bits of road)
but in places where there's only one real ref per piece of tarmac
(such as the UK) there's no need to force mappers to start
maintaining relations as well as just recording the reference.


Well, I believe impetus for route relations was Sustrans networks.
These tags went from the ways to relations years ago already, so call me
skeptical that there's no multiplexes in the UK (especially since
without any real effort inside 30 seconds, just randomly scrolling by
hand to the UK, I see that the A24 and RCN CS7 are multiplexed).  I
honestly don't see why we should be treating tags related to route=road
any different than we're already treating route=bicycle.


There's not really any 'multiplexes' in the UK.
There are a few places where A roads appear to overlap.for a short 
distance. But its really one road number disappearing, while the other 
continues. So each section of road will only have one official number, 
and only one of the road numbers will be signposted.


Yes, cycle routes do follow numbered roads. But that doesn't change the 
number of the road, it still only has one main ref. If you asked someone 
cycling along there, they would still say they are on the A24.



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

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

[Andy Townsend]

On 06/11/2015 13:44, Paul Johnson wrote:
On Fri, Nov 6, 2015 at 7:02 AM, Andy Townsend > wrote:


Obviously in places where a road can have multiple equivalent
references (such as the US) route relations perfect sense (as does
figuring out which routes are actually signed on which bits of
road) but in places where there's only one real ref per piece of
tarmac (such as the UK) there's no need to force mappers to start
maintaining relations as well as just recording the reference.


Well, I believe impetus for route relations was Sustrans networks.  
These tags went from the ways to relations years ago already, so call 
me skeptical that there's no multiplexes in the UK (especially since 
without any real effort inside 30 seconds, just randomly scrolling by 
hand to the UK, I see that the A24 and RCN CS7 are multiplexed).  I 
honestly don't see why we should be treating tags related to 
route=road any different than we're already treating route=bicycle.




Sure - there are lots of route relations (such as Sustrans' cycle 
networks) in the UK, but (over here) that's separate from the reference 
of the road.  It's also fair to say that Sustrans' route labelling can 
be "variable", to the point where "the signs on the ground", "the route 
they'd like to use" and "the official current sustrans route" can be 
three different things.  As an aside, Sustrans recently changed their 
official route for some routes just south of where I live to match the 
signs on the ground (and therefore OSM, which was mapped from those) as 
what OSM had was actually more a more sensible route than what they 
had.  Where there is this variability in signing, you can't always 
expect someone (especially a new mapper) to fill in all the details of 
cycle routes that a bit of road is part of, though a cycling fan can 
usually come along and fill in the gaps.  However a new mapper can read 
the reference on normal road signs and should be able to fill in the 
"ref" on the way without difficulty.  The tricky bit (in the US) is 
having a UI in e.g. iD that can guide them through the "add to existing 
nearby route relation".


Both iD and P2 can show nearby relations, but for example at 
http://www.openstreetmap.org/#map=19/53.07007/-2.04161 both also show in 
the relations that you might want to add to a way the relations that a 
way is already part of, and super-relations of other relations (which it 
doesn't need to be added to).


None of this is easy, and iD (correctly in my view) tries to hide 
relation functionality if it can.  I'm just suggesting to try and keep 
it simple where its possible to do so (i.e. don't create route relations 
where it's possible to express the same concept in a simpler way).


Cheers,

Andy (SomeoneElse)




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

 

On 2015-11-06 14:26, Dave Swarthout wrote: 

> I was looking at a what I surmise to be a ferry route earlier today and it 
> had a tag of route=fairway. Did the mapper not realize what he was doing or 
> are the diagnostic tools for determining errors in relations not that robust?

Are you sure that route=fairway is wrong? It can have a nautical
meaning: 

https://en.wiktionary.org/wiki/fairway 

//colin ___
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 Fri, Nov 6, 2015 at 7:02 AM, Andy Townsend  wrote:
>
> Obviously in places where a road can have multiple equivalent references
> (such as the US) route relations perfect sense (as does figuring out which
> routes are actually signed on which bits of road) but in places where
> there's only one real ref per piece of tarmac (such as the UK) there's no
> need to force mappers to start maintaining relations as well as just
> recording the reference.
>

Well, I believe impetus for route relations was Sustrans networks.  These
tags went from the ways to relations years ago already, so call me
skeptical that there's no multiplexes in the UK (especially since without
any real effort inside 30 seconds, just randomly scrolling by hand to the
UK, I see that the A24 and RCN CS7 are multiplexed).  I honestly don't see
why we should be treating tags related to route=road any different than
we're already treating route=bicycle.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Mike N]

On 11/6/2015 8:00 AM, Christoph Hormann wrote:

Stop rendering this key and instead render the relations

Is there*any*  map style that does this at the moment?

AFAIK osm2pgsql does not support including relation membership info in
the rendering database.


The US developmental version at 
http://tile.openstreetmap.us/osmus_shields/preview.html#14/39.9272/-86.1812 
gets its information from relations - the only way to properly show such 
roads carrying multiplexed routes.


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

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

[Dave Swarthout]

On Fri, Nov 6, 2015 at 8:02 PM, Andy Townsend  wrote:

> Obviously in places where a road can have multiple equivalent references
> (such as the US) route relations perfect sense (as does figuring out which
> routes are actually signed on which bits of road) but in places where
> there's only one real ref per piece of tarmac (such as the UK) there's no
> need to force mappers to start maintaining relations as well as just
> recording the reference.


I'm glad someone else said it first. I don't want to be forced to create a
relation where one is not needed. Relations are tricky, the tools for
handling and editing them are IMO not that good, and it will invite many
mistakes by less experienced mappers. I was looking at a what I surmise to
be a ferry route earlier today and it had a tag of route=fairway. Did the
mapper not realize what he was doing or are the diagnostic tools for
determining errors in relations not that robust? Hell, when I'm adding
inners within a large multipolygon I don't even think there is a way to
determine exactly which relations surround my area. In addition, editing a
relation which shares nodes/ways with another relation is a pure nightmare.

No thanks. Before you go ahead with something like this, please make sure
the tools and the Wiki are up to the job.

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

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

[Andy Townsend]

On 06/11/2015 10:24, Paul Johnson wrote:


Even in European cases, thanks to "E" routes in the EU, this is 
decidedly not a strictly North American situation.




Not really, or at least not across the board.  In some European 
countries "E" roads are paper routes only - they're made up by non-local 
beaurocrats, are unsigned, and irrelevant for all route planning purposes.


Obviously in places where a road can have multiple equivalent references 
(such as the US) route relations perfect sense (as does figuring out 
which routes are actually signed on which bits of road) but in places 
where there's only one real ref per piece of tarmac (such as the UK) 
there's no need to force mappers to start maintaining relations as well 
as just recording the reference.


Routers ought to already know what country they're in when routing 
(though the recent US maxweight discussion worries me that they may not 
all do this) so it really shouldn't be an overhead for them.


Cheers,

Andy (SomeoneElse)

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

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

[Christoph Hormann]

On Friday 06 November 2015, Paul Johnson wrote:
> Stop rendering this key and instead render the relations 

Is there *any* map style that does this at the moment?

AFAIK osm2pgsql does not support including relation membership info in 
the rendering database.

-- 
Christoph Hormann
http://www.imagico.de/

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

2015-11-06 11:24 GMT+01:00 Paul Johnson :

> Even in European cases, thanks to "E" routes in the EU, this is decidedly
> not a strictly North American situation.




I agree with your analysis and the proposed fix (maybe we can be faster
than the deadline you suggest). FWIW, even without E-routes there are
overlapping routes in Europe (e.g. in Germany), but admittedly compared to
the US it is a rare phenomenon.

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

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

[Paul Johnson]

ref=* on ways has become an unmitigated hot mess for maintainability, and
now that relations have been around for a considerable amount of time.
Let's kill this dinosaur like Linux killed ext filesystem support already.
It's so long in the tooth it's starting to go from egregious to just sad.

*Background*: Prior to 2007 and the 0.5 API, OpenStreetMap had no
"relation" data type, just nodes and ways.  A stopgap measure to deal with
routes was to tag them on ways.  However, this quickly developed into a
major issue as routes with their own refs for different modes and
memberships cropped up as OSM developed past being merely a traditional
street map.  Relations were introduced, and quickly adopted as the standard
tagging for routes of all kinds, with tags for most networks moving off the
member ways to the relations.  Presets for creating road routes with
relations exist in (at least) JOSM and have for years now (I'd consider it
a glaring, almost egregious, omission for any general purpose or
highway-oriented editor at this point).

*The problem:* It's now been 8 years since the introduction of relations,
and only route=road seems to be the sticking point for consistent route
tagging, with qualities that should be part of the relation are instead
still getting legacy-tagged on ways.  This ends up being a major
maintainability nightmare in places where multiple routes share the same
way, especially whenever a new route is introduced or an old route is later
deleted, and only gets worse the more routes share the same way (Illinois
being an extreme example with some highways carrying as many as 9 signed
routes), or the more road networks in play (Texas being an extreme example
with 7 state level networks).

There's also the situation where ways themselves have their own refs often
disconnected from the route (Oregon for sure for any highway with no route,
all highways prior to 1928 and most highways 1928-2007, which is to say all
but ~20-30 highways statewide) and possibly Pennsylvania (with the
four-digit state highways) has this situation, but PA's case might just be
a borderline case of routes with unsigned-ref).

Even in European cases, thanks to "E" routes in the EU, this is decidedly
not a strictly North American situation.

In any case, adding or removing members and checking the relation's
consistency is far easier, and easier to validate, than juggling multiple
ref values in any sort of coherent fashion.  And this is before even
getting into issues of *which order* the refs go in...

*The fix: * I propose a goal of December 31, 2016 to eliminate ref=* as a
method to describe an overlying route; this should be more than ample time
for existing data consumers to catch up on doing a move and ensure data
consistency for routes.  Kill the dinosaur:

   - Deprecate ref=* on ways from having anything to do with the routes
   they run over, use relations instead and phase out the use of
   route-describing refs on ways (be it removal of the tag or replacement of
   the key's value with a ref that actually applies to the way instead of the
   route).
   - Stop rendering this key and instead render the relations in opencarto
   and other featured layers.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging