I have few meta comments and then actual comments. Meta:
In this case, the discussion has been entirely reasonable. But, in general, I feel there's an unwarranted hostility to imports. I think this comes from fear (often justified) that people who don't care about following community norms will dump in lots of data without following guidelines (and I agree this is bad). But, we should be careful not to discourage people who are acting in good faith and who are willing to respect community norms. I'm happy to see that this discussion has been more of a "we want to help you do this right" than a "imports bad! go away!" kind of tone. I am local to this import. I've hand drawn buildings in my town, and I'm probably the only one who has. For my town, I would be ok with replacing my buildings with the import (preserving building tags) because I think the new data is high quality. But we're not talking about that. (Jason and I have been discussing this offline. We are near each other, but haven't met in person yet. We will probably organize an in-person meeting for East Central Mass mappers in early 2013 (basically Routes 495/2 give or take 50 km.) Detailed comments: 1) I support this conceptually. We've had building footprints near Boston for a long time, and I think they are very useful both in the mapnik map and in using the data when converted to Garmin format. 2) I believe the licensing issue is ok. MassGIS has always made their data available with no strings and just a request for attribution. The state is using OSM data (http://trailmap.mapc.org/), so it seems that MassGIS is somehow aware of what's happening. 3) I'd like to see an English description of what the processing script does in the wiki. This is partially so that other imports can use it as an example. I think it's - shapefiles converted from MA state plane NAD 1983 to 900913 - imported into postigs - existing OSM data also into postgis - building polygons selected if they do not overlap a building in OSM - selected buildings exported to .osm format but it would be nice to say it precisely in text. 4) I realize it's convenient, but I think using google is to be avoided. People who care about privacy won't want to have google cookies or ids, and OSM should be able to have infrastructure for this. Perhaps bittorrent is a good solution for large chunks of bits 5) AIUI, the guidelines call for imports to be done from an import-only account. There's no reason why a user foo who is going to upload data can't create a foo-massgis account and use it. Accounts should absolutely not be shared (one account => one human knows the password). 6) It seems that after step 3, the data is quite high quality. The big concern is damaging existing work, but I think the postgis select really works, and it's easy enough to spot check. I have personally loosely spot-checked the Stow file, and also merged it and current osm data and converted it to garmin and watched it while driving (being driven!) around. It really looks like Jason's avoid-conflicts code is right. But it's good to have more eyes on the data. There are so many buildings that it's not really possible to hand-review every one. That's ok, and the questions are - are we messing up data already in osm (no, because of overlap filtering) - how does this do in terms of getting closer to the goal ("every building has an accurate roof-/foot-print, and no roofprints are present for things that are no buildings). Of course, spurious data is worse than missing data, but my quick looking found no spurious data, and it sounds like there are very few from Jason's private comments to me. So I think the review should focus on looking at the output of the script to produce the candidate upload, and seeing if that's ok. If we really look at a few towns and things seem ok, then I think it makes sense to upload everything. If they aren't ok, the scripts should be fixed and we should iterate. 7) I agree with previous commenters that we should start slow. I think it makes sense, once we've resolved all the process issues, for Jason to upload a single town, after he's looked over the data (and identified the town so others can look). Then we can let that hit the renderer and people can convert to garmin, and see what we think for a week or so before continuing. There will be only a single changeset in a limited area (with a known data steward!) to revert if something goes wrong. 8) I don't think we should try to preprocess the data to remove outlines that seem off. There may be a few outlines where there aren't buildings, but they are very few and can be cleaned up later. I think there will be less trouble with a very small number of people doing uploads, but we should ask locals to review the data and opine if it's ok. For example, if I study my town's proposed bits and decide it's good, I think it's just fine for Jason to do the actual upload. 9) It would be polite to offer to Massgis that they can use information about outlines that we think are errnoneous. I know they can't use ODBL data, but I would grant permission to them for those deletions by me to be public domain. I don't know if they have cycles to cope, though. This argues for uploading all footprints (that don't overlap) for a town in one changeset, and then deleting the spurious buildings, if any, for that town. (I haven't found any in my town yet.) All in all my comments are fairly minor and I think this is on the right track. Greg
pgplCz7tp7Txh.pgp
Description: PGP signature
_______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
