[Talk-us] [Imports] Kansas City addresses from maps.kcmo.org
baloo at ursamundi.org
Sat Jul 30 20:14:39 UTC 2016
On Fri, Jul 29, 2016 at 3:02 PM, Frederik Ramm <frederik at remote.org> wrote:
> On 07/29/2016 03:42 AM, Clifford Snow wrote:
> > Thanks for pointing out my lapse. You are correct. I've used parcel
> > boundaries for parks a number of time.
> Nonetheless (in order not to confuse the original poster) let's
> reiterate that property lines themselves do not belong in OSM; only
> where they can be used to deduce the bounds of something we *do* want in
> OSM will they find their way into the database. We will not map
> individual property lines in e.g. a residential neighbourhood (much less
> import them).
This feels like a usage case, somewhat specific to a far more gruanular
scenario, in part of OSM's self making.
At least in the US, even in residential areas, there's a high degree of
difference between landuse=highway and landuse=residential. I get that
land use changes over time, but, are we trying to produce a static map, or
a flexible map? I'm generally on the assumption of the latter (though my
examples of Oklahoma as a whole and Oregon's Metro Region plus Clark
County, Washington as critters with their own quirks) seems to be fairly
unique. Particularly with three-dimensional tagging in place, is there a
reason to NOT handle property-lines on the ground?
I mean, Tulsa Oklahoma's only something like the ~924234324 largest city in
the world, by way of a number I totally pulled from deep under my tail (in
reality, it's one of the largest metropolitan or micropolitan statistical
areas in the US; top 100 even, out of 929 metro or micropolitan areas in
the US, as defined by the census, for which Tulsa metro is 57th largest in
America), but even having a statistical baseline literally good enough for
government work, and usually (always?) surveyable based on identifying
markings at the extreme corners...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Talk-us