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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >

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

>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

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

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

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

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

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

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

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

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

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

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

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

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

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

@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

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

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

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

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

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

On 2015-11-06 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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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.

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

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