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 <[email protected]> _______________________________________________ Talk-us mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-us
