[Imports-us] Florida Water from Land Cover Import

Serge Wroclawski emacsen at gmail.com
Fri May 31 14:48:11 UTC 2013


On Thu, May 30, 2013 at 11:11 PM, Brian May <bmay at mapwise.com> wrote:
> Hi List,

Hi Brian!

Thanks for joining and getting involved!

> Another OSM user and I are proposing to tackle manually importing water
> derived from the land cover shapefiles produced by the Water Management
> Districts. In addition, we will update coastlines. We would also like to
> explore utilizing the wetlands and forest polygons from the land cover,
> however, I know there are potential problems with shared polygon borders and
> I'm not sure the best way to go about that.

This is a lot, so for my own clarification, I'd like to break these
down. So if I understand you correctly, you're looking to:

1. Update water areas (lakes, ponds)

2. Update of coastlines

3. Wetlands and forests

For the sake of managing complexity, I think it'd be easiest to think
of these as entirely separate tasks, even if they're from the same
dataset.

I'm going to be speaking about the lakes and ponds, and not about 2,
3, which I think warrant their own discussions. Would you be willing
to hold off on those until the water features are done?

> I have seen a fair amount of NHD data that has been imported in parts of
> Florida, and from what I have seen so far, the water polygons derived from
> land cover are much more accurate, detailed, and up-to-date.

That would make sense, and it's a shame Florida (like so many other
states) have poor data. But we have a wonderful opportunity to improve
the situation!

> Some manual import work using this data has already been done, so partly
> we're "coming clean". I have read the import guidelines and kept up with
> this mailing list. In the past, I have subsetted out the water from the land
> cover SHP by selecting it in ArcMap and exporting to a new shapefile. Then
> used shp-to-osm to convert to OSM XML, loaded it into JOSM, and then
> copy/pasted the ways into the main OSM layer.

Can you paste some of your changesets?

My view is that so long as:

1. The data is properly licensed
2. You're making proper attribution (wiki page and then source= in chageset)
3. You're doing data conflation and not simply plopping it down on top
of the existing data
4. The new data is accurate
5. The data is properly tagged
6. The new data is properly simplified

Then there's nothing wrong with this kind of import, and manual
imports are, for the most part, better.

It sounds like you've gotten the message about some of these and are
taking corrective action, so that's great. I want to stress that most
of the time, data from external sources needs to be simplified before
inclusion in OSM, so you'll want to add that to your process.

And if you need any help, we can certainly help you!

> So, the next steps are to further flesh out the wiki page detailing the
> process, provide some sample OSM files for review, and discuss with the US
> OSM community before we do any more importing. We would also welcome any
> others who have an interest in helping out with the effort.

Sounds good, and if you'll be in SF this week, I think I'll set up a
BoF after my import talk (not immediately after, but at some point
during the conference).

Usually with imports there's an issue of update. I'm personally less
worried about updates on these water features. Lakes rarely change.

Rivers and streams do need to be handled differently, though, and if
you have any of them, we'll want to address them separately from the
ponds and lakes.

Thanks again for joining and making everyone aware of the work you're
doing. If you'll be in SF, please point yourself out!

- Serge



More information about the Imports-us mailing list