[Talk-us] Seeing things you don't care about in the database

[Alan Mintz]

At 2012-06-11 16:17, Mark Gray wrote:
>it is also much better for being sure you are oriented when
>you are out there and can see the buildings on the map line up
>with real buildings. Address and POI information looks much better
>with the context of the buildings they are associated with.

I can't quite agree with this, unless you're flying a helicopter :) I don't 
see much relation between the outline of a building from the sky and the 
appearance from the street, other than general density - maybe how much of 
the block is spanned by one building.


>I think that one of the strengths of OSM is that people can map
>what they are interested in, whether it is roads or railways or
>hiking trails or power lines or bike racks or local businesses.
>OSM is definitely getting beyond "just streets" in many places and
>I think that is a good thing to be encouraged and celebrated.

I agree, except that I think we have to make sure we can accommodate those 
things. While I agree with what has been said about people needing 
satisfaction from their work, we also need to make sure the project as a 
whole remains viable. In order for that to happen, people need to use it. 
The vast majority of that audience need - at least - an accurate street 
network.


>If you want to just edit some streets, though, you should not have
>to download and render every object in the area and have them all
>active as things you might want to make a junction with.

Exactly. I think the problem and solution could be simpler than some might 
think, though. The biggest issue, in my experience, is building footprints, 
with individual lot-size landuse polygons close behind. Building footprints 
(ways) do not need to intersect with any other type of feature. While some 
people like to draw landuse polygons all the way out to the middle of a 
street and join them with the street, most mappers don't, and don't like 
this practice for various reasons. It's also not the way imported landuses 
are, since they are generally from a taxing authority, and represent the 
space on which the owner is taxed (which doesn't include dedicated 
easements for streets and utilities). I believe separating these two items 
into their own layers solves the problem, and can be done without a 
strategy for dealing with intersection between layers.

In San Diego, CA, an import of individual address nodes was done (from 
SanGIS), which slows things down. These are not actually joined to anything 
else, and so could be separated to their own layer. This is not the case 
for this type of data in general, though, so some strategy needs to be 
adopted for this, too.


>If I invested in getting JOSM working again and learned all its
>tricks could I do this today?

Possibly. I haven't played with the latest, but I think the mirror 
downloader can now support the Overpass API more fully, and it now supports 
the ability to filter out specific types of features. If/when this works, 
we at least have the makings of a "virtual" separation into layers, though 
there is nothing currently present to enforce the non-intersection.


>  Lately I have just been using
>Potlatch 2. It is so easy to navigate to the place I want to work
>on the rendered map, switch to edit mode, edit, scroll to the
>east, edit, save, done. When I used JOSM I missed the simplicity
>of the Potlatch work flow so much, but I might be willing to try
>again.

You would have to in an area with building outlines (like Bakersfield, CA). 
Potlatch becomes too slow to be usable at anything but the highest zoom levels.

I'm happy this issue is getting some attention.

--
Alan Mintz <Alan_Mintz+OSM at Earthlink.net>