[Talk-us] Seeing things you don't care about in the database
Alan_Mintz+OSM at Earthlink.Net
Tue Jun 12 16:21:59 BST 2012
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
>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
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>
More information about the Talk-us