On 11/19/2015 07:13 AM, Paul Johnson wrote:
Obviously there needs to be a sunrise for consumers to catch up, but
eventually the dinosaur needs to be killed. There's some places where
the way has a ref unique to the route, as noted on the ground, that
currently isn't easy to map thanks to the associated tag already being
used to identify the ref of an entirely different entity (the route
relation). I'm also suggesting that the quicker we do this, the more
painless it'll be.
We should probably bear in mind how we got here. There's a natural
tension here between the different uses of refs, that should be made
explicit.
Those who gather data in the field map what they see. I get on the
freeway near home, and I see signs "Interstate 890 East/NY 7 West."
(Newcomers get confused all the time about the fact that "east" on the
one route is "west" on the concurrent one.) At that strictly local view,
"ref" is a cluster of values - it's the multiple things that are on the
signs. That's what a nearsighted mapper sees. In this view, the topology
of the highway grid is an emergent phenomenon.
Similarly, to the renderer, the question to be asked is, "what shield or
cluster of shields shall I put on this way?" That's again a purely
local, nearsighted view, and comes down to "what's on the sign?"
If collecting mapping data from mappers or rendering maps were all that
we cared about, we'd stop here. Collect what's on the signs, render
what's on the signs, we're done.
And that's how OSM got started, and for a while everyone was happy. Some
people still are, I suppose. But with refs existing just on the ways, we
lose important capabilities.
We want to be able to route, and generally speaking, I imagine that
routers will favour staying on the same numbered route. (I could be
mistaken, they may simply disfavour roads of lower quality or getting on
and off freeways unnecessarily.) In any case, the traffic engineers
generally number routes with the idea that they link destinations. A
driver heading from Schenectady, New York to Bennington, Vermont can get
fairly simple directions of "follow NY 7 east all the way to the state
line, where it becomes Vermont 9. Take Vermont 9 the rest of the way
into Bennington. The fact that NY 7 makes several twists and turns over
local streets, and is briefly concurrent with NY 2, or I-87, or NY 22
(and so on) might be noted as "watch out, the highway turns here," but a
driver could follow the directions just as I gave them. That's why we
have numbered routes.
And it's entirely sensible to ask questions like, "what cities does NY 7
visit?" or "what route does the Northville-Placid Trail take for the
section where it's following the paved roads in Piseco, NY?"or "what are
the mileages between exits on I-87?" If all we have is the clustered
text on the signs, then these are the sort of questions that most
database managers are very poor at answering, because there's really no
alternative than parsing the text of each sign, separating it out, and
discarding those ways that don't match. Furthermore, such a question now
comes back with a disconnected bucket of ways, without topology, so the
program answering the question has to reassemble the ways into a route -
and it may not even be possible to do so.
With route relations, it becomes simpler. "Troy Road between Crosstown
Blvd and the Northway interchange is bannered NY 7,"
"The Adirondack Northway is bannered I-87 for its entire length" "The
Adirondack Northway between exits 6 and 7 is bannered NY 7" become
discrete facts, that are easily queried either by route or by way.
The disadvantage is that life becomes a trifle more complicated for the
renderer. Instead of dealing simply with ways that have all the refs in
one place, there's a subquery to get the cluster of refs that belong to
a given way. This isn't all that hard, but Mapnik doesn't do it yet.
Rather than try to get functionality like that into Mapnik, what Phil!
Gold did with his clustered-shield proof of concept was to update the
bannered ways with clusters of refs when importing the data, and then
have the renderer deal with those clusters (with pre-rendered graphics
for the shields). This approach had the advantage that the changes to
the Mapnik symbolizers were minimal, but came at the expense of some
truly weird database logic (made weirder by the fact that it also has to
incorporate refs on ways). I use his code, because it was too much work
to reimplement it, but it's far from ideal.
In any case, any database designer wants to have a given piece of
information in only one place. If refs are on both routes and ways,
that's a potential for their becoming inconsistent between the two.
Starting from the "mapper and renderer" perspective, refs on ways made
sense, but moving forward, it makes things insane for routers, route
queries and the like. Assembling reference for routes, by contrast, is
fairly straightforward to do in the database. A database that can
actually support GIS (such as PostGIS, SpatiaLite, or Oracle Spatial)
can surely support subqueries to retrieve the refs. Failing that,
auxiliary tables that organize refs by way could be invented, but I
prefer not to go there.
I don't think any formal decision has been made to deprecate refs on
ways, but all of us looking at the problem agree that they're not a
sensible approach. Someone who's familiar with database design would
identify them as not being in even "first normal form," which is the
among the weakest sets of constraints without which a relational
database cannot function.
Now we need to get organized on the task list to make it happen. We have
the right brains here to do it "bottom up." I have some thoughts on it,
but don't have time to set them down right now. Maybe I'll follow up
tonight. They break down into, "help the mapper," "handle the data
import," "help the renderer process concurrent routes," "provide for
legacy renderers," and "get the existing mess retagged."
--
73 de ke9tv/2, Kevin
_______________________________________________
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
