[Imports] [Talk-us] Fresno castradal imports

[Paul Johnson]

On Fri, May 4, 2012 at 12:22 PM, Ian Dees <ian.dees at gmail.com> wrote:
> On Fri, May 4, 2012 at 1:48 PM, Paul Johnson <baloo at ursamundi.org> wrote:
>>
>> On Fri, May 4, 2012 at 11:43 AM, Ian Dees <ian.dees at gmail.com> wrote:
>> > On Fri, May 4, 2012 at 1:37 PM, Paul Norman <penorman at mac.com> wrote:
>>
>> > Do those individual polygons have any useful information on them
>> > (addresses,
>> > for example)? If so, we should generate addr points from their
>> > centroids.
>>
>> Why?  We have these new things called computers that find centroids
>> really well.  And the way it's mapped now, it makes it really easy to
>> change a specific lot if the land use changes.
>
>
> Right. So the computer can find the centroid and generate the addr: point
> for us. Perfect. (I realize you're saying the data should stay in OSM, but
> read on...)

Why strip the information that creates that calculation?  Land use
could change, as well, based on condemnation, natural disaster, etc.
Having the plot outlines give nice, fine-grained control that will
greatly simplify disaster mapping in the future, and the outlines will
be of use if the boundaries of the use change (combined or subdivided
or whatnot) in the future.

>> > Either way, we could save useful OSM information by creating a new
>> > polygon
>> > from the outside edges of each block. basically, remove all overlapping
>> > nodes except the ones on the outside. This way we maintain (semi-)useful
>> > landuse information and remove the extremely noisy tax plat information
>> > that's there already.
>>
>> Sure, it's noisy, but it's not like we don't have tools to squelch
>> what's not interesting for a specific use case or edit session.
>
> The problem with this import is that is the complete opposite of the "on the
> ground" rule. There is absolutely no one but the external source of that
> import that can improve the data. I have the same opinion of other
> boundaries (I can't go to the coordinates of a particular node along that
> way and see the boundary on the ground, verifying it with my GPS), but can
> live with it when they're big and unobtrusive.

So what's wrong with refining the data to fit what's on the ground?  I
seem to recall I made your argument regarding the TIGER imports about
3 years ago when I was new.  This is certainly a more accurate and
detailed data set than TIGER was; why step backwards?