Re: [MappingDC] Reviving the "import" of DC GIS' buildings data set

[Brian DeRocher]

Chris,

It's nice to have you aboard! I hope we can help you as much as you're
helping us.

As you know there was a 2009-2010 effort to import the DC GIS data which
sadly fizzled out. I'm so glad that we're revisiting this. Serge, who
was involved before with MappingDC and the DC import, is now working on
an OSM import "committee". So he can give some good guidance there.
From the MappingDC community, we can surely support you.

Just wanted to let you know that credit for the previous import is
expressed here:

http://wiki.openstreetmap.org/wiki/Contributors#District_of_Columbia_OCTO

So my first question is, what do you plan to do for the buildings that
were already imported? When you say "lot of the building polygons...
are out of date" do you mean 3-4 years old, or WAY out of date? Would
you update them with new polygons? How will you conflate them?

Martijn did took a look at some stale DC data, looks like streets only.

http://oegeo.wordpress.com/2012/07/03/a-look-at-stale-openstreetmap-data/
http://mvexel.dev.openstreetmap.org/dcstaleness/ (evidently has no tiles)

Breaking up work into Census tracts is a great idea. In the past we
used MapCraft to break up work, assign it to ourselves, and track
progress. Maybe this is useful here. You just upload an OSM file of
areas to get started.

http://mapcraft.nanodesu.ru/pie/217

Can you provide links to the changesets where you updated the Capitol
Hill houses.

Here's an odd and perhaps silly question: If you have two buildings
which share a corner in real life, does your workflow create one node or
two? Will the simplify process merge them? If that's the
Douglas-Peucker type of simplification, i don't think so.

I was looking for a good map of DC buildings colored by age, but could
only find this. It happens to show the results of the Falls Church
mapping party.

http://www.itoworld.com/map/127?lon=-77.07088&lat=38.89570&zoom=12

thanks again,
Brian

Brian DeRocher
http://brian.derocher.org
http://mappingdc.org
http://about.me/brian.derocher


On 05/19/2013 01:52 PM, Chris Andino wrote:
> Hello,
>
> I'm relatively new to active OSM editing, and a complete novice at
> imports. I've come back to OSM mostly as a useful way to blow off
> steam after work that is more productive than watching Kitchen
> Nightmares. Living in Near Southeast, I noticed that a lot of the
> building polygons in developing areas of DC are out of date, and that
> few buildings exist on the map outside of downtown.
>
> I've put together a proposed workflow for doing a semi-manual import
> of the building data that combines the address data from a different
> DC dataset to minimize the need for weeding out tag cruft and copying
> and pasting tag data. I did a trial run on one fairly large block of
> Capitol Hill houses; the semi-manual import took about four minutes
> for ~80 structures.
>
> I've put together a fairly thorough write-up of my proposal here:
> http://www.sixpica.com/osm/2013/05/19/proposal-for-importing-dc-gis-building-data-to-osm/
>
> Feedback and comments would be welcome. I'd like to work out kinks and
> get MappingDC buy-in before forwarding on to imports-us for discussion.
>
> Best,
>
> Chris Andino
> --
> You received this message because you are subscribed to the Google
> Groups "mappingdc" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mappingdc+...@googlegroups.com.
> To post to this group, send email to mapp...@googlegroups.com.
> Visit this group at http://groups.google.com/group/mappingdc?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Chris Andino]

Brian,

Thanks for all the cool ideas here. The main takeaway is that I should probably refine the scope of this method to only cover the 20% or so of DC buildings that have yet to be imported, coming up with another method to check for updates/changes to existing buildings. To answer your questions:

1. I haven't thought that much further beyond completing the empty zones of town, most of which are in NE and SE. As the GIS data is at least two years old, there will be some noise there (new buildings will not be in, some buildings will have been razed), but it should provide a good baseline for future perfection.
a. That said, this exposes the need to potentially add in the 'CAPTUREYEA' tag. That date represents when OCTO conducted the underlying survey (i.e. the last date the building was physically verified to be that shape, size, and location). pubdate, on the other hand, is simply the date that DC published the ESRI shape file. Both are potentially useful. For one, it could help automate the process for finding buildings that have changed or to conflate two versions in the future. I would propose that if the polygon with the newer capture year was different, that it replace the older polygon, which would be deleted. This would be pretty tedious in places that aude/serge have already completed, but the staleness exercise suggests that it might be possible to do this programmatically comparing, for instance, polygons that had >99% overlap (which would allow for minor variance due to the GIS simplification) and leaving those out from the resultant shapefile. I think that's out of scope for this exercise.

2. MapCraft looks like a much more sensible way of breaking out the data, even if it does end up just being me doing it. Thanks!

3. Can't provide the links for my test run, because I didn't save it to the API. I did a "dry run" as proof of concept and then navigated away without saving so as to not add a ton of data without first consulting people who know more than I do. That said, I did do a single building in near south east that I happened to know had a different footprint than what had been in the OSM data: http://www.openstreetmap.org/browse/changeset/16198240

4. I think what you're asking is if, say, two houses share a wall, what's the deal with the node that marks, say, the front corner of their houses. The raw data from the dc dataset only has one node there, shared by two ways, so it's "pre-merged". The simplification did remove some mid-point nodes on straight lines.