Re: [Talk-us] MapQuest Open Maps now has proper state shields

[Craig Hinners]

I like the fact that they took some artistic license and used "stylized", or "iconified" shields, rather than trying to do a perfect pixel-per-pixel resize of the prototype shields. The latter method does not necessarily produce good on-screen results. (Which is to be expected, given that the prototype shields and fonts were designed for reflective lighting at sizes on the order of feet, rather than emissive lighting at sizes on the order of millimeters.)Case in point...maybe it's just my twisted mind, but...when I look at the Indiana state route shield at http://elrond.aperiodic.net/shields/, I see "DOGMAN" instead of "INDIANA" if I'm more than about two feet from my screen. :) Compare that to MQ's version, where they apparently think that using a square is "good enough", and do not try to reproduce the "INDIANA" legend or use the FHWA font for the digits.There is a balance there somewhere, between being too stylized while still having a level of realism that satisfies us road geeks who can spot the difference between FHWA Series C and D characters that are a few pixels in size. Personally, I think Google's Interstate shields are too stylized (the blue color they use is horrible) as are their US shields (which almost look like plain old circles); MQ seems to have struck the right balance of size and detail.

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Network tag Re: Highway Shield Rendering

[Craig Hinners]

Chris Lawrence :
> modifier=* would represent MUTCD-type banners attached to the shield

This is the first I've heard of this tag. I don't recall it being
discussed when we were hashing ideas around on this last summer. (Not
that that is reason to discount it.)

But what came out of that discussion was the following guidance: "ref"
will store "the unique identifier within a particular classification",
where "particular classification" is stored wholly in the "network" tag.

So, "network=US:US:Business"/"ref=13" and "network=US:US:Truck"/"ref=70"
both conform to that definition.
"network=US:US"/"modifier=Business"/"ref=13" does not.

Are "US:US:Business" and "US:US:Truck" "true" networks? Perhaps not.
Would it be "correcter" to separate "truck" and "business" into other
tags? Perhaps. Is storing "business" and "truck" within the "network"
tag causing confusion for data consumers and not a workable solution?
Doesn't look like it from the proof of concept renderer posted on here.

Chris Lawrence :
> That said it may be easier to combine modifiers/banners into the
> network as subtypes. Renderers can fallback to the longest
> left-anchored substring they understand for weird things they don't
> understand.
> Whatever folks want to do (including modifier -> banner)
> would be fine with me; it's not like there are thousands of relations
> that would need to be changed to the consensus that emerges.

Agreed...good points.


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Network tag Re: Highway Shield Rendering

[Craig Hinners]

Phil! Gold :
> It seems to me that network=US:US:Business:MD is the logical extension of
> a scheme that has US:US and US:US:Business.

My initial reaction is that this goes too far in mixing geographic,
classification, and rendering concepts, which has a bad smell:

* It forces one to state explicitly what is already available implicitly
somewhere else: if a renderer wants to display a Maryland-specific US
Business shield, then it can already do so by determining whether the
point at which the US:US:Business shield is to be rendered is within MD.
Alternatively, the renderer could look for a "responsible agency" or
"owning agency" style tag. (I don't even know if such a tag exists,
admittedly.)

* It forces mappers to have knowledge of which agencies use non-standard
shields, so that they can break the relations at those agencies and add
the agency-specific tag. (Whereas, where agencies use the "standard"
shield, relations can stretch over agency boundaries.)


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Network tag Re: Highway Shield Rendering

[Craig Hinners]

Nathan Edgars II :
> It seems that many people see the network tag as not representing a 
> network but a shield design. Does this sound accurate?

No, because, where shield designs differ by agency for the same logical
network classification, the network tag does not change, despite the
differing shields.

One of many examples: Maryland uses a unique green-on-white shield for
US Business routes, but those roads still get tagged as
"network=US:US:Business", not "network=US:US:Business:MD" or somesuch.
The renderer would have to detect which agency the road is "in", and
render the agency-specific shield accordingly.


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Route Relations and Special (Bannered) Routes

[Craig Hinners]

This was discussed in the August 2011 thread, "Use of ref-tag on state
highways".

At the time, a number of people seemed to be on board with the
"network-classification-per-banner" scheme, as in:
 network=US:US:Alternate
 ref=1

Or, something similar at the state level:
 network=US:VA:Secondary
 ref=7100

I think all that really remains is to formalize/define the valid values
for the various federal- and state-level "network" tags in the wiki.


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Medians and reverts

[Craig Hinners]

>> [Richard] Clearly these evil paint-separated commuter lanes are a gateway 
>> way to one-area-per-lane micro-mapping. [...]
> [Paul] I'm not seeing how the slippery slope argument applies [...]

Nor am I.

Choosing to model distinct, disparate, and incompatible traffic flows as
a single flow when they are separated by paint, but as discrete flows
when they are separated by anything other than paint, strikes me as an
inconsistency for a traffic flow model.

I'd also like to defend the concept of a single-way-per-lane model as a
noble goal rather than a pedantic endeavor. There are useful concepts
that I'd like to convey that I cannot, due to the current
multiple-lanes-per-way model. While acknowledging the cost (in time and
effort) of implementing it, I'd submit that a single-way-per-lane model
is the penultimate model of traffic flow.


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Medians and reverts

[Craig Hinners]

Paul Norman 
> I would not separate a road with a double-yellow in the middle into two 
> separate ways

And millions of miles of two-lane roads with opposing flows have been
modeled in OSM as single ways. But why?

I'd submit that it's because the current de facto usage of ways is to
model "contiguous areas of improved driving surfaces", not "traffic
flows".

To prove my point, if I milled out a one-foot wide swath of asphalt
where the double yellow lines are to create a "median" consisting of
nothing other than dirt, but changed absolutely nothing else in regards
to the traffic flows, I'd suddenly be expected to model this in OSM as
two discrete ways.

All I've done is replaced paint with dirt. I've changed nothing in
regards to the legality of transferring between the flows (paint or
median, I still am not allowed to transfer between the flows). I've
changed nothing about the physical ability to transfer between them (I
can drive over a patch of dirt as easily as I can drive over a stripe of
paint). Yet I've changed how I model them.


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Medians and reverts

[Craig Hinners]

What to model as discrete ways has always struck me as a gray area in the OSM model.
 
I'm of the opinion that, at locations where traffic may not or can not transfer from one linear flow to another, the flows should be modelled as discrete ways.
 
The reason for the inability to transfer between flows should not be a determining factor in deciding what to model as separate ways. If I can't transfer between flows, I want to know that; whether the reason for being unable to transfer is stripes of paint or a 10 foot tall concrete barrier or a median of weeds and dirt is not germane.

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] REST Services

[Craig Hinners]

The county must be running ESRI stuff on their back end, which is why they are exposing their data via ESRI's REST API. That would also explain why their imagery is supported in ESRI's tools.
 
JOSM would need to support this ESRI REST API in order for you to consume the county's data. If JOSM doesn't already have this support baked in, it may be able to be added to JOSM via a plugin. That might be a worthwhile endeavor if a lot of agencies are starting to publicly expose their data via this API.
 
By the way, if I recall correctly, JOSM uses another ESRI API for USGS imagery, which is based on XML web services (which is way more complicated and verbose than REST). So if JOSM is able to use that ESRI API, I have to think support can be added for this other one.
 
But I'm nary the JOSM expert. Is there a JOSM mailing list?

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Use of ref-tag on state highways

[Craig Hinners]

I tend to think of business, truck, loop, alternate, etc. as logical
subnetworks, or sub-classifications, of their respective networks. Just
a different way of thinking, I suppose:
 
"50" is the unique designation within the "Business" sub-classification
of the "US Highway" network (i.e, US:US:BUS)
 
as opposed to
 
"50 Business" is the unique designation within the "US Highway" network
(i.e., US:US)

I see what you're saying about Arkansas, in that their treatment of US
business routes on signage "feels" more like a "different designation".
On the other hand, Maryland uses a totatally different shield design for
business US routes (basically a green-on-white US shield), which is more
of a "distinct network" feel.
 
Either scheme allows data consumers to differentiate business and
non-business networks, but we probably ought to standardize on one or
the other.

 
 
 Original Message 
Subject: Re: [Talk-us] Use of ref-tag on state highways
From: Nathan Edgars II 
Date: Wed, August 24, 2011 6:37 pm
To: talk-us@openstreetmap.org

On 8/24/2011 6:25 PM, Craig Hinners wrote:
> FWIW, I agree with all of Jason's suggestions, below, for the
> relation-level "network" tag values. It mirrors my thinking on the
> matter exactly.

I disagree with putting alternate and business in the network. These 
modifiers are part of the designation, and some states (Arkansas in 
particular) treat them as lettered suffixes rather than separate plates.



___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Use of ref-tag on state highways

[Craig Hinners]

FWIW, I agree with all of Jason's suggestions, below, for the relation-level "network" tag values. It mirrors my thinking on the matter exactly.
  

 Original Message Subject: Re: [Talk-us] Use of ref-tag on state highwaysFrom: Jason Straub Date: Wed, August 24, 2011 3:37 pmTo: "talk-us@openstreetmap.org" 
As the person that just got done labelling each TX state highway, I'll chime in here with some comments.For the network tag, I think that the labelling should be (country : state network : network within the state : subnetwork in state), while the ref is JUST the number for that highway.  So:US:I -> InterstateUS:I:BUS -> Business InterstateUS:US -> US RouteUS:US:BUS -> Business US RouteUS:US:ALT:BUS -> Business Alt US RouteUS:TX -> Texas State HighwayUS:TX:FM -> Farm to MarketUS:TX:RM -> Ranch To MarketUS:TX:FM:Bus -> Business Farm to Market

Having been through most of the highways in TX at least, this works for all that i've labelled, whether it's still that way or not.  I prefer to have the final labels show the state abbreviation and number (TX 10) instead of generic state labeling (SH 10) (TX has state highways, not state routes), but am willing to work with either.  Once a useful mapping tiling appears that uses state shields, this wont matter nearly as much.Jason25or6to4>network=US:TX:SR>ref=10>= Texas State road 10>network=US:FL:Orange:CR>ref=10>= Florida Orange county road 10>network=US:TX:FARM>ref=10>= Texas State Farm road 10>Wouldn't this just use one US in network?>network=US:BUSINESS>ref=50>= US Business 50

___Talk-us mailing listTalk-us@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-us

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Use of ref-tag on state highways

[Craig Hinners]

> Alan Mintz alan_mintz+...@earthlink.net
> For FM 1960, I'd use:> network=US:TX> ref="FM 1960"
 
I'd prefer to put all of the network information in the "network" tag, keeping the "ref" tag as a pure container for "the unique designation within the network":
 
network=US:TX:FARM
ref=1960
 
Similarly, instead of this style of tagging of US business routes (example found in Salisbury, MD):
 
network=US:US
ref=50 Business
 
I'd prefer:
 
network=US:US:BUSINESSref=50

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] GPS overreliance anecdotes (WAS: Women trust GPS, drive SUV into Lake)

[Craig Hinners]

Reminds me of when, on the first day of a new job, I accepted a ride with my new co-worker to join others at the traditional "lunch with the new guy". He didn't know the way to the restaurant, but I did, having checked OSM prior to leaving. No matter, he insisted on obeying his GPS and ignoring me. I bit my tongue, what with being the new guy and all. Three wrong turns, two missed expressway exits, and one illegal u-turn later, we arrived at the restaurant. Fifteen minutes late.
 
I should have taken that as a harbinger of things to come; to wit, the job only lasted a few months.

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] REF tags for State Highways on ways

[Craig Hinners]

So it's clear from the responses that there are differing needs here:

Due to regional differences, displaying the two-letter USPS code in the shield is not necessarily desirable. For example, there are states where "SR" is more easily understood.
At the conceptual level, the same string should not be used to represent the networks of multiple states, and some state-unique ID, be it the USPS two-letter abbreviation or otherwise, is needed.
Currently, the "ref" tag does double duty for both conceptual and rendering level concerns. That's the root cause of the problem here, and will continue to be, until the conceptual-level data is moved out of the "ref" tag into its own tag(s).
 
There is nothing stopping anyone from tagging state highways with conceptual-level tags this instant. One could, say, add "highway:network:us:fl=123" tags to Florida state highway 123, leaving the ref tag as "SR 123". Map users see something they're familiar with ("SR" instead of "FL"), and automated agents of OSM data get a unique key to identify the concept of "that network of highways in the US state of Florida". It's a win-win.
 
Of course, it would be desirable to have consensus on the syntax of the conceptual-level tag, be it "highway:network:us:fl=123", or "highway:network=us:fl:123", or "highway=fl:123", but that's a diversion from the crux of the issue, which is the overloaded use of the "ref" tag.

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Relations, cycle routes, shapefiles

[Craig Hinners]

>[The "rich key" methodology] still can't handle ways that are part of more than one route (e.g. situations like the I-580, I-80 overlap are actually fairly common).It can, using semicolon-delimited values. Your example becomes:highway:network:us:interstate=580;80As an aside, if OSM didn't have the limitation (or benefit, depending on your point of view, I suppose) of not supporting identically-keyed tags on the same object, I'd prefer to use multiple tags with the same key [on the same way]:highway:network:us:interstate=580highway:network:us:interstate=80

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Relations, cycle routes, shapefiles

[Craig Hinners]

Sure, relations get you an additional degree of normalization. And using relations to carry route/network tags gets the job done, granted. But at what cost?I've yet to hear a convincing argument that justifies the additional complexity of relations as they are being championed as carriers of route/network tags, nor have I heard why applying tags with highly-specific keys directly to ways is so fundamentally flawed that it warrants the added complexity of relations.As if to prove my point, the whole reason this thread even exists (if my understanding is correct) is that those who are trying to import data from other GIS formats (Shapefiles) are being stymied by the fact that the tags-to-relations-to-ways model turns a non-trivial task into a head scratcher.So, what this tells me is that, while insistence on a one-relation-per-logical-route methodology results in a normalized, one-to-many schema, it creates an artificial barrier for those seeking to add data to OSM. I, for one, will gladly accept the tradeoff of not being able to trumpet the fact that my dataset is "normalized" in return for lowering the barrier for others to enrich the map.If I had my way, I'd tell these people to forget about relations and simply tag the ways that comprise the cycleways with tags like cycleway:oregon=3A, cycleway:oregon=9, cycleway:oregon=Sunset Ridge Trail, etc., and be done with it. (I have no clue whether those are legitimate route numbers/names for cycleways in Oregon; I'm just using them to illustrate a point.)And, unlike the current situation of keys-that-aren't-really-keys, cycleway:oregon represents one concept, and one concept only: cycleways in Oregon. Unlike, say, a "ref" tag, you won't find it on cycleways in Ohio, or highways in Ottawa, or bus routes in Oslo, or oil pipelines in Oman. Want a map of the Oregon cycleway network? Hello OSM API, give me all the ways with tag.key==cycleway:oregon. Want to render the Oregon cycleway shield? Do so if the tag.key==cycleway:oregon and put the tag.value in the shield. No parsing...no additional DB JOINs...no collisions with other tags on the same way.

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Relations, cycle routes, shapefiles

[Craig Hinners]

The only thing that relations add (in terms of tagging) is an order of magnitude of complexity.There is no technical reason why direct application of tags to ways can't work. However, this requires the use of highly-specific tag keys, such as a unique key for interstate highways, a unique key for U.S. highways, a unique key for [insert your state here] highways, a unique key for [insert your state here] bikeways, etc.For whatever reason, though, the de-facto practice became cramming everything under the sun into the values of tags having non-unique keys, such as ref, to the point where said tags mean everything while at the same time mean nothing.The concept of key/value pairs is common in computing, where the key describes a unique concept in the dataset: interstate, U.S. hwy., etc. However, now that ref has taken on thousands of different meanings depending on context, it can hardly be considered a "key" any more, to where it has zero utility outside of rendering (i.e., displaying its value in a "shield"). Which is quite ironic, if you think about it, given how we're constantly berated to "not tag for the renderer".Hence the reason why everything breaks down when, god forbid, there is a way that belongs to two classes of networks (say, interstate and U.S. hwy.), because you now have to somehow convey multiple concepts in a single tag (ref). Which is why the operative workaround is to resort to another layer of abstraction (and complexity) in the form of highly-specific relations, when everything could have been taken care of in the first place with directly-applied tags having conceptually-unique keys. 

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)

[Craig Hinners]

> > On 10/15/2010 09:44 PM, Richard Welty wrote:
> > Sans prefices, the highway=motorway where US Highway 10, Wisconsin Highway
> > 66, and Interstate Highway 39 run together would have ref=10;66;39.  Not
> > very useful for determining which is which.

This is why I keep arguing for using *non-ambiguous tag names*: the
"what" should go in the tag name, and the "which" should go in the tag
value. So, instead of the current situation where we have half a
bazillion ways with a "network" tag name, you'd have:

network:country[US]:unitedStatesHighway = 10
network:country[US]:state[WI] = 66
network:country[US]:interstate = 39

(Or, if you're of the brevity and ambiguity trumps verbosity and clarity
camp, I give you "network:US:WI", "network:US:US", "network:US:I".)

Point being, by making a clean separation between the "what" and the
"which", it makes it easier from the standpoint of an automated agent of
OSM data, be it a renderer or whatnot: you have a clean query on the tag
/name/ to get all routes of a certain classification (the "what"),
regardless of /which/ route number it is.

No endless parsing of the tag value, looking for "I-" to determine
whether that way is an interstate, oh, oops, this guy doesn't like
hyphens, I need to look for "I*", oh, oops, that gets me everything for
Iowa and Idaho, oops, now my function to determine whether a way is an
interstate is 1 lines long with 500 "if" statements and regular
expressions that would make a CS major run for the hills.

No, none of that. Simply: if tag name =
"network:country[US]:interstate", render the AASHTO shield with the
number(s) in the tag value. Easy peesy.

No arguing about relations, super relations, super duper relations,
relations of relations of relations of sub-relations, orphan relations,
bastard relations, divorced relations, etc. You just tag the ways with
these non-ambiguous tag names. Relations are WTFs of complete and utter
proportions.


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Fwd: Re: [OSM-talk] Mapquest launches site based on OSM!

[Craig Hinners]

> From: Paul Johnson 
> Perhaps Richard could shed some more light on this, but relations are 
> pretty much going to be necessary to properly render route shields given 
> the huge variety in highway networks in North America and the world.

My company has a beta version of a renderer that displays the proper
shield, be it interstate, U.S. highway, state, county, or whatnot,
without using relations. To do so, it looks for the following tags on a
way (i.e., /not/ on its relations):

network:country[us]:interstate = 95
network:country[us]:unitedStatesHighway = 1
network:country[us]:state[md] = 99

It also does proper multi-shield rendering of multiplexed routes, be
they of the same type...

network:country[us]:unitedStatesHighway = 50;301

...or disparate:

network:country[us]:interstate = 70
network:country[us]:unitedStatesHighway = 40



___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Rendering of semicolon delimited values (WAS: Would Like To Clean Salt Lake City Street Names)

[Craig Hinners]

> From: Kevin Atkinson 
> If a stretch of road has multiple numbered route, a semi-colon
> should be used to separate them and I believe that the render _will_
> recognize those.

In my experience, Mapnik renders the semicolon as-is, rather than
creating a shield/marker for each individual route number.

But don't exceed a certain quantity of characters, because then it won't
render a shield at all. The limit is different for the various values of
the "highway" tag: it was 6 and 8 characters when I bitched about it
some years back:

http://trac.openstreetmap.org/ticket/937

Anyway...yet another example of how this practice of cramming every last
bit of highway network metadata into the value field of a "ref" tag has
its limitations...


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Fwd: Re: [OSM-talk] Mapquest launches site based on OSM!

[Craig Hinners]

From: Nathan Edgars II 
> There's been no standard way of tagging state highways since before I
> joined at the beginning of this year.

Nor has there been in my four years here. Hell, I was the one who wrote
the wiki suggestion to use the USPS state abbreviations. I am completely
and utterly stunned that it is still there.

One of my four OSM WTFs is overloading the REF tag's value with so much
information. We should be "key rich", not "REF value rich". The *keys*
should have the "meat", not the *values*:

network:country[us]:state[ks] = 10// renderer sees this and
renders a sunburst
network:country[us]:state[md] = 26// renderer sees this and
renders a white rectangle

These tags are simply applied to all of the ways that comprise the
route. No complicated relations (the second of my four OSM WTFs)
necessary.

Need all of the ways for a route? It's a simple database query: SELECT *
WHERE key = 'network:country[us]:state[md]' AND value = '26'.

If you have a state with different classes of networks, you just extend
this idea:

network:country[us]:state[va]:primary = 7 // renderer sees this and
renders a guitar pick thingie
network:country[us]:state[va]:secondary = 606 // renderer sees this and
renders a circle

If you have a way that is on two networks, you just give it both tags:

network:country[us]:unitedStatesHighway = 40
network:country[us]:interstate = 70

Oh, yeah: this also gets rid of those asinine arguments about, say,
whether there should be a hyphen in the REF tag between the "I" and the
digits in interstate designations. Don't like the hyphen? Knock yourself
out, and create a *renderer* that shows "I 95" when it encounters
network:country[us]:interstate=95. Prefer hyphens? Or a shield?
Whatever. The point is, that's the domain of the *renderer*, not the
*metadata*.

Moving on, if you have a way that comprises two networks of the same
class, you hit OSM's third WTF, which is the inability to have two tags
with the same key:

network:country[us]:unitedStatesHighway = 50
network:country[us]:unitedStatesHighway = 301

So as a workaround, you have to use the infamous semicolon:

network:country[us]:unitedStatesHighway = 50;301


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Gluing boundaries to roads (was Talk-us Digest, Vol 31, Issue 1)

[Craig Hinners]

> This is a three minute video on, mostly, maps and addresses. Probably applies 
> to boundaries too. http://sivers.org/jaddr

Interesting. Although, I don't know what it is, but TED speakers always
manage to creep me out and sound supremely sanctimonious, no matter how
enlightening their subject matter is.

Back to OSM: as a traffic engineer, I'll submit that we realign roads
all the time, to straighten curves, widen, etc., but, somehow, I don't
think the administrative boundaries are changing with them.

The OSM concept of having points as first class entities in the data
model, rather than just waypoints on polylines, makes it very tempting
(and convenient) to "glue" edges of disparate entities. On a small
scale, this is handy: that park that fills up a block or cemetery that
borders a road renders a lot better if you glue them to the surrounding
streets. But add a point to one or the other, and, depending on your
editor, it's not guaranteed to be added to both entities. Oops.

Also, you have to consider that the current OSM model of modeling only
centerlines may change one day (say, tomorrow), to, say, modeling lanes,
curbs, or edgelines. Then what...which lane is the administrative
boundary? I'd rather not go there.


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us