I think that this import was poorly done but overall I don't see the problem with having this type of data in OSM. In fact, I think it is really useful and<br>don't entirely understand the backlash against it. I would really enjoy having that kind of base to work with.<br>
<br>So, Thoughts on Plot and Building data in OSM.<br><br> A. Great for rendering. (Generaly this is probably why all these imports happen the way they do.)<br> 1. The way Mapnik displays landuse data as different colors allows renders to display useful and interesting information visually at a very fine grained way.<br>
2. Some maps render the plots directly and it can look very nice. For instance, Google Maps renders the parts of San Francisco this way with the plots as very faint lines. It looks great<br> and conveys more information.<br>
i. Yes, this could be done by rendering OSM and then rendering the plot data separately. This could, however, be said of everything in OSM. The OSM model isn't everything in a separate layer, it is<br> everything altogether. What makes plots unique in this regard? Why do we want them separate?<br>
<br> B. Editing. (I think the problems here are part of the reason for the hostility towards imports, especially ones of this type)<br> 1. Building and plot information greatly decreases the download area because of the 50K object limit. Some people like to do edits over large areas and this makes that difficult.<br>
For instance, in this thread someone mentioned they have 68000 square kilometers they want to work on. I edit almost exclusively in a city that is ~120- square kilometers of land.<br> I don't think we're going to get a whole lot of consensus on how dense the data should be with these types of differing use patterns. I would look at having all the building outlines<br>
as a godsend while others look at it as a problem because they can't download an entire area as easily. <br><br> Personally I take this as an indication that our tool chain really needs more work. The 50K object limit is what is getting in the way of mappers with this problem, not the data itself.<br>
Even in San Francisco where, other than the streets and some GNIS nodes, there really hasn't been any imports this limit gets in the way. How do mappers in places with really dense non-imported<br> data deal with this issue?<br>
<br> 2. Dense building and plot information greatly increases the file size that editors have to cope with and many of them can't, especially for large areas. Again, I don't think a consensus<br> is going to be easy to find here. I want dense data, building outlines and plots. I think that is useful for many purposes. Others aren't interested in this type of data and find it nothing<br>
but a nuisance. Again, maybe better tools will help but I think we're more likely to see this type of data multiply rather than disappear.<br><br> 3. This one is more subjective but the first thing I thought when I zoomed in on the Fresno data was "awesome." I get the impression other people (most?) think "eww, what a mess!"<br>
I would enjoy that kind of base to work with and expand on even if imperfect. Building outlines would be better but plot information would be great, too. Mostly it would just be so much<br> easier to tag a pre-existing area instead of having to trace one from scratch every single time you want to add a park, or school, or fire station etc to the map. If the area didn't look right,<br>
edit it. I think people look too much into the plot data being "official" and "owned by someone else." Once its in OSM its ours and we own it.<br><br>This import does have its problems but whats the rush to delete it? Without imported data Fresno would pretty much just be a white place on the map. The streets are all tiger import, many of the POIs are<br>
from the GNIS import and almost all of the rest of the data is from this one and little of any of it has seen much editing. Are we really making a more useful set of geodata by cleaning out <br>the plot info here?<br><br>
Cheers,<br>Greg<br>