<div dir="ltr">On Sun, Dec 30, 2012 at 5:51 PM, Jason Remillard <span dir="ltr"><<a href="mailto:remillard.jason@gmail.com" target="_blank">remillard.jason@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<br>
<br>
On Sun, Dec 30, 2012 at 11:09 AM, Serge Wroclawski <<a href="mailto:emacsen@gmail.com">emacsen@gmail.com</a>> wrote:<br>
> OSM is not data repository, it's a dataset onto itself. Through years<br>
> of experience, and trial and error, we have found that importing these<br>
> external datasets does not help the project in most cases. Therefore<br>
> we propose different solutions to some of the problems.<br>
<br>
I don't think this is the majority view.<br>
<br>
- Imports are officially allowed. We have a process defined for doing them well.<br></blockquote><div><br></div><div style>We don't, actually (just because there's a page on the wiki doesn't make it official or defined). This is a source of much frustration and one of the reasons why Serge has brought together a group of interested parties to work on such a thing.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- Steve Coast, the project founder, just three months ago asked for a<br>
crazy huge import for addresses.<br></blockquote><div><br></div><div style>Steve says lots of crazy things in order to move OSM forward. Importing addresses from reliable sources is one of his least crazy ideas. :)</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">When 98% of the data in US was already imported, it seems a kind of<br>
late to be even having this discussion. It is really absurd to ask<br>
people who are are interested in imports to go someplace else, when<br>
imports are a huge part of the map in the US (this is talk-us right?),<br>
have been for a long long time, are happening every single day, are<br>
officially allowed, have the support of the majority of the people in<br>
the project, and our founder just three months ago asked for a new<br>
huge import for addresses. Nobody should be getting asked to leave<br>
over this issue.<br></blockquote><div><br></div><div style>I don't think anyone is being asked to leave. We are asking people to be careful about the data they dump into OSM. Some data doesn't belong in the OSM dataset.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">In 2009, the "open space" layer from MassGIS was imported in<br>
Massachusetts. Most of the landuse=conservation in the state come from<br>
this import. I started mapping this year, noticed the problems, and<br>
decided to fix it. I used my local knowledge (I am a member of one of<br>
the local conservation groups), bing images, walking around,<br>
talking/emailing my neighbors, and the MassGIS L3 parcel data. None of<br>
these sources are 100% correct. The authoritative parcel data is not<br>
available to OSM because of a bad license my town uses. I did my best<br>
to synthesize what I think is the most complete and accurate map of<br>
the conservation land. It has been a ton of work figuring this all out<br>
(10x more work than the building import). As far as I know, OSM is<br>
only place to get this information with a good/liberal license. I<br>
think that most (but not Frederik!) people in the project would agree<br>
that this is a net improvement to the map.<br></blockquote><div><br></div><div style>Using external data to improve OSM is great. Adding park/conservation area boundaries based on a combination of local knowledge, aerial imagery, and stuff like the MassGIS data is great.</div>
<div style><br></div><div style>On the other hand, when you string "importing" and "parcel data" together in the same sentence you're setting off all sorts of alarms because a) importing has historically implied "adding crappy OSM data". Even seasoned users like myself have done a piss poor job (e.g. the county borders or some NHD stuff) and b) parcel data implies tens of thousands of abutting polygons (which means they need to be 'glommed' and multipolygon 'relationified'), a huge glut of useless data added to the database, and complaints from users who use editors that aren't designed to handle data density.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I would also like to point out, I was *not* looking for a huge heated<br>
conversation about the scope of OSM, pushing people off to other<br>
projects, etc when I posted my question. It was just a couple of very<br>
small questions about data that has been in the db since 2009. I am<br>
frustrated that my thread was taken over like this. We should rename<br>
this mailing list "import-fighting-us-plus-frederik".</blockquote><div><br></div><div style>To be fair, you asked a very open-ended question and had a very (inadvertently) bait-laden subject line.</div><div style>
<br></div><div style>Your original question was "<span style="font-family:arial,sans-serif;font-size:13px">what should the exact criteria be for including an '</span><span style="font-family:arial,sans-serif;font-size:13px">open space' parcel in OSM?" and I think your answer is that there shouldn't be exact criteria. As frustrating as it is sometimes, there aren't exact criteria for anything in OSM.</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">Having said that: you should map things that are verifiable by another mapper on the ground (parks, schools, hospitals, named open spaces) and you should not import generic parcel data. You agreed with that in your second sentence, but there were plenty of messages in this thread talking about it :).</span></div>
</div></div></div>