How to correctly draw landuse areas

Hello,

There is an area I want to mark as landuse=commercial. The are is bounded by streets on all its sides. Should I glue the area to the streets’ control points or should I put the area points adjacent to the street?

Thanks,
FireAphis

I would leave a small distance to the street.

Since half of the street and the sidewalk is not commercial (unless it’s a pedestrian street with pushcarts - hmmm) you should probably draw it offset. It’s also less annoying for those editing streets :slight_smile:

Thanks. On the same matter, if there is a commercial area inside a large residential zone, can I put the commercial over the residential? Logically it is problematic since then there will be two uses to the land. But how can make a “hole” in the residential area?

I guess this is where you start having to apply the wonderous multipolygons
http://wiki.openstreetmap.org/wiki/Relation:multipolygon

Hmm… seems like an overkill to me. It’s a too common scenario to use such an advanced technique. I did see that in various places commercial areas just on top of the residential.

I think that Mapnik will render that fine, but if you generate a map with mkgmap, you will start to have to worry about polygon draw order and TYP files or else you may find that the commercial polygon plots underneath the residential polygon and so is invisible.

Oh :frowning:
Maybe I’ll fragment the residential area then. I really prefer to avoid multipolygons.

The landuse-tag denotes the main landuse of an area. Different landuses should not overlap.

Only for some special cases (like farmyard within farmland) I would allow overlap.

When you have overlapping areas like here (landuse=military/forest):

http://www.openstreetmap.org/?lat=51.7708&lon=7.3334&zoom=14

you get an ugly map where you are not sure what is rendered on top.

Chris

They’re not as hard as you might think! :slight_smile:

Especially not with the multipolygon plugin in JOSM.

On the other hand, multipolygons have created problems and continue to do so.

The old style multipolygons (exactly one “outer” which has to be a ring and is bearing all the tags; the relation has no tags other than “type=multipolygon”) introduces somehow false entries into the database.
Example: the ring way says “It’s a lake” and the multipolygon says “Oh no, not really, remove these island areas first”. So we have elements in the database (the ring ways), which should or should not be interpreted depending on the contents of another element (the multipolygon) in the database.

The new style multipolygons are rather clean. All the tags are in the multipolygon entry and all tags in any of it’s elements are just describing this element as an object which is independent of the object described in the multipolygon. But we cannot use these properties completely, as we have to think about the mixup of both descriptions.

Using the same type name “multipolygon” for both of them was a really bad decision as it puts a too heavy burden on the analysis part of the renderers, robots and other programs using the database. Even if it is possible to distinguish both types, it’s just an error prone situation.

My personal conclusion is:

  • I don’t create old style multipolygons
  • All the “outer”-elements I use are either free of tags or definitely non-areas.

Weide

Not sure what you mean by old and new style multipolygons. Can you explain a bit more?

He means the complicated way of creating Areas with multipolygons and several way members that together build an area. In that case you must put the Tags on the multipolygons because the ways itself are not a closed way.

The are more cons using this type of multipolygons:
a) New Users can’t change anything in that area because many new users don’t understand multipolygons
b) It’s very difficult to understand the areas for experienced users if you have several of such multipolygons next to each other You have to open every multipolygon in JOSM, select all members on the map to understand the areas.

I remove such complicated multipolygons whenever I encounter such a construction and convert them into a single way that generates an area.

There is only one reason why this multipolygons are possible and why they make sense: If you have a very large Area like a large lake and you have to split the area way into several parts because of the 2000 node limit for ways.

Keep it simple if you can should be one of the basic rules.

But there are sensible reasons for using these advanced mps. For instance, if you’ve got a field bounded by three roads and an industrial area, it makes sense to use each section of road and part of the industrial area poly to generate a multipolygon describing the field.

Ah yes, I see now. Thanks. Some may say “flexible” rather than “complicated”, but I take your point and agree it’s not easy :slight_smile:

FireAphis’ question does highlight an issue that is starting to trouble me more and more though, and that is whether the fundamental structure of the database is still the right one.

What I mean is, that OSM started out (I guess), as the name suggests, as a map of “streets” - i.e. a network of connected nodes - where each node has 0 dimensions and each connection has 1 dimension. This represents a routable road network really well (obviously) and the addition of tags gave richness and “width” to the connections to render them pleasantly.

But the ground could also be considered as a set of interconnected areas where each area butts up against its neighbour. Fields and lakes are obvious but a road takes up space, motorways considerably so, and could be modelled as an area in its own right.

We have ended up with the database trying to support both models and so we have the situation where some people define an area by a single way running just inside the ways that bound it (like the 1st advice above) and others that define areas by the ways that bound it using multipolygons.

Is the original concept still fit for the purpose of what people now want to use it for?

Does this trouble anyone else or do I have too much time on my hands?!

@Seventy7:
I find the OSM model troublesome too. There is too much emphasis on the “way” concept. Ideally, I would like OSM to resemble the 1:2500 plans used by surveyors, at least when closely zoomed, which means treating roads as areas.
Looking at some suburban localities reminds me of an overcooked tagliatelli, or my very old A-Z atlas of central London, where most roads are wider than they are long. and no room at all for buildings. I am beginning to find it hard to fit in buildings, etc. between the roads in my town and retain good resolution. We need to create variable road widths at least: highway=residential_narrow doesn’t work yet, and won’t be enough; railway lines take over cities like the plague (Helsinki) and I can’t put the jetties in a marina near me because I know it will look like an airport terminal.

If there was a hedge (or a fence) between the road and the field, one would walk with their GPS to the hedge and could then stand there for a while to get a better approximation of the location, which is at least some meters to the side of the road. Follow the hedge to the next corner of the field, and draw the hedge as a separate way next to the road. Surely everybody would agree that it would then be wrong to draw the field as existing on both sides of the hedge when there’s a field only on the other side?

Now if the hedge is cut down, does the size and shape of the field change? It doesn’t, so the presentation in OSM shouldn’t change either.

The way represents the highway AND the sidewalks. So we have to admit that the street borderline is in every cases incorrect. If you want to be accurate, you should draw polygons also for the streets. But since they are symbolized with a line, it is also valid to attach the landuse to the line. Both methods are correct. Otherwise I could also say that an offset suggests that there is “something” between the landuse and the street. A good example is a pedestrian square along a street. If you keep an offset between the street way and the pedestrian area, you don’t connect both objects and pedestrian routing will fail.

A way is only the middle line of a street and nothing more.
You can either use an area for a street (too complicated in my opinion) or add a width tag.
The rendering engine can draw an area if you have both values.
The alternative is a fixed width for different street types that is used today.

OSM isn’t very easy for new users who are not nerds, this complicated multipolygones are too much for them. You would end with a map that can be only edited from the few OSM experienced experts. That would be an epic fail if you think that this doesn’t matter.
I could point you to übercomplicated areas in the map with such multipolygons where even experienced users will have really huge issues to understand the areas but I converted them one by one to simple areas.

I think that you have to understand that OSM will never show the 100% reality that exists ion the ground. We are trying to get close to the reality but it’s always a compromise.

Our data model doesn’t allow more but that is enough for the sources of our data.
Aerial images are shifted and we have only 7m accuracy for GPS.