vehicle-centric standard? [LWN.net]

vehicle-centric standard?

Posted Sep 29, 2009 22:23 UTC (Tue) by roelofs (guest, #2599)
Parent article: TomTom unveils OpenLR location-referencing format

OpenLR seems remarkably automobile-centric for a standard proposed by a European company. Virtually everything refers to roads; there is no concept of a bicycle-only, bike/pedestrian-only, or pedestrian-only path. (The only almost-exception is the TRAFFICSQUARE form of way, which describes "an open area ... which is used for non-traffic purposes," but even that is "(partly) enclosed by roads" and obviously doesn't capture the bike- or pedestrian-path concept.)

One of the major mapping services (Google, I think) recently noted several of the problems with such an approach: there are roads and bridges on which pedestrians and/or bicycles are banned (e.g., freeways); roads on which vehicles are restricted to a single direction but pedestrians (and possibly bikes) aren't; and obviously paths, walkways, etc., on which vehicles are banned (and perhaps also on which bicycles are banned or impractical, such as stairways, trains/subways, or the Pacific Crest Trail). If you're explicitly looking for a bike route to work or a pedestrian path in a remote tourist location, vehicle-oriented GPS receivers and mapping services are often useless.

Greg

(Log in to post comments)

vehicle-centric standard?

Posted Sep 30, 2009 0:06 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]

true, but it would still be FAR better than the current situation where everyone keeps the data walled up and separate.

if someone has a suggestion as to how to alter the proposed standard to better support these other options, by all means make it.

however, you don't want use of this to flounder due to efforts to make it perfect.

it's a lot easier to supplement a vehicle-biased database like this with additional data than to create it from scratch.

vehicle-centric standard?

Posted Oct 1, 2009 3:23 UTC (Thu) by roelofs (guest, #2599) [Link]

it's a lot easier to supplement a vehicle-biased database like this with additional data than to create it from scratch.

Good points all, but the flip side is that standards become much harder to change after everything's baked in (unless they're explicitly designed for extensibility, like PNG), and many early adopters never get around to updating their code to later versions. In this case, both of the fields I mentioned are explicitly limited to 3 bits, i.e., just enough to support the 8 values they've already defined, and I see no allowance for any sort of "escape value" or other form of extension. Seems like premature optimization.

I'll try to submit a comment to their standardization process...

Greg