User talk:Nakor

Relation analysis tool

Just curious - do you know of any semi-automated way to analyze a relation and pick out continuous segments, then label them with direction roles like north/south? For example, 378803 378803 has single-carriageway and dual-carriageway portions, but not all of the latter are tagged properly. --NE2 07:03, 25 January 2010 (UTC)

Hi, I have my own script on the toolserver that gives me the segments. It is still experimental, it is pretty slow and fails with long relations. It as a couple improvements over the one at emaitie.de: works with roundabouts and better handles the direction relations, effectively stitching together the separated and non-separated portions of the highway. You can try it if you want for your relation that would be [1]. From this result I still have to fix the relation manually. Nakor 14:45, 25 January 2010 (UTC)

Awesome - I just rediscovered this and it handles routes like SR 436 perfectly. Thank you very much. It would be even better if it could find sections that need to be tagged - in other words, identifies loops created by dual carriageways beginning and ending, and splits it at one end. It also won't handle situations like SR 50 where there are directional roles and other custom roles (in this case, a new flyover being built for SR 50 traffic). --NE2 04:50, 9 February 2010 (UTC)

I am not sure what you mean with finding sections. Do you have an example. For SR 50 I tried to improve a little bit. Let me know what you think. Nakor 03:02, 11 February 2010 (UTC)

SR 50 looks good - obviously I would just ignore the construction entries.

With sections, say you have single carriageways A and D, connected by eastbound B and westbound C, none tagged with roles. Depending on the lengths of these segments, the tool might return ABD, ACD, ABC, or ACB as the continuous route. I don't know how easy it would be to identify the "triple points" where B and C end, and output B and C as separate segments that need to be tagged with roles. --NE2 09:42, 11 February 2010 (UTC)

No idea what's causing it, but the script is currently giving errors ("%d format: a number is required, not str" in the line "database.query('SELECT role FROM roles WHERE relation=\'%d\'' % self._relation_id)"). --NE2 13:26, 9 March 2010 (UTC)

Yes I broke it yesterday evening while implementing some new functionnalities. Hopefully I will fix it sometimes today. Nakor 16:21, 9 March 2010 (UTC)

Not sure what's happening here - it had been working, then I corrected the north/south roles to east/west and added the North Carolina end. Could it have the north/south somehow cached, or determined from the location of the termini? --NE2 10:19, 10 March 2010 (UTC)

Yes, some information are not retrieved correctly from cache so the first time it works fine but not afterwards. Nakor 15:23, 10 March 2010 (UTC)

Here's an interesting situation. There's a turn restriction eastbound, so you have to make three rights to turn left. But the script doesn't know that, and treats the loop as a separate segment. I have no idea if this is worth dealing with. --NE2 21:26, 16 March 2010 (UTC)

Thanks to your tool, all mainline U.S. Routes (and E/W and N/S splits) now have relations! Now all that needs doing relation-wise is unbraiding a few in Polk County, Florida (ugh) and maintaining (which your table makes easy). One suggestion would be to put the "notes" column in that table if it exists; I've gotten hung up several times on the gap in US 61 before realizing it was supposed to be there. --NE2 23:33, 19 March 2010 (UTC)

Relation analysis

On http://toolserver.org/~nakor/relation.fcgi?relation=419295 and some other routes that change direction, it doesn't put the directions together properly (it's south-east and north-west), leading to incorrect routability information. It might be easiest to simply display all possibilities no matter how many segments.

Also there seems to be a problem with supperrelation handling, but this may be harder to fix: http://toolserver.org/~nakor/relation.fcgi?relation=271863 --NE2 06:07, 21 June 2010 (UTC)