<div>Replying to a Newbies thread, but beyond the scope of that list so I moved here.<br><br>I've been thinking about layers for a while. In OSM we do not use layers for different types of features as one would in traditional GIS. I suppose the benefit of this is simplicity, but in very dense areas, things can get very cluttered and hard to edit. <br>
<br>One result of data overload seems to be that mappers want to minimize duplication (I include myself in this group). If there is a case where two areas overlap on one side, we convert them to multipolygons that share a way where they overlap. This is good. But how about when an administrative boundary is directly on top of a highway or a river for miles and miles? The nodes blink at you in Potlatch. Surely two ways are unnecessary and one way shared by a relation for the boundary and a relation for the highway/river would be better, no? There has been lots of discussion about if and when it is correct or not correct to do this. I have flipped back and forth on this question, but lately it has occurred to me that the use of layers could nullify the whole debate. If layers were built into the OSM data structure, administrative boundaries could have their own layer. Layers would not be able to share objects, so the question of highways and boundaries sharing ways would not come up. If a boundary happened to exactly follow a road, one could simply copy the way from the highway layer to the boundary layer and change the tags. Later if someone wanted to edit the road but not the boundary it would be quite easy to select the road by simply turning off the boundary layer and vice versa.<br>
<br>Clearly too many layers could make OSM far too complicated. Here are two that I see a real benefit to having though: <br><ul><li>Physical - everything that is verifiable by going somewhere and looking around. </li><li>
Non-Physical - administrative boundaries, nebulous place names, landuse (not land cover which is physical). Basically things that can only truly be verified by laws & treaties (national boundaries), or things that are not well defined but clearly agreed upon (Most people know where the Alps are, but there is no exact boundary)</li>
</ul></div><div>I see a benefit to these being separate because a non-physical feature can be defined by a physical feature, but that does not make it the same as the physical feature. Take the boundary of a forrest and the boundary of a field for example. As more trees grow, the forrest expands and the field shrinks. The boundaries for these two physical features are one and the same. Now take the boundary of a township, county, or state that is defined by a river. As the river changes course over time, the boundary of said political entity may or may not change depending on how the law is written. Though they may coincide, the two are not inexorably linked as the boundary of a field and a forrest are.</div>
<div><br></div><div>Let me qualify this post by saying that I participate in this project only as a mapper and I have no knowledge of how the underlying database or API works. There are probably many technical challenges and/or reasons not to do this that I haven't though of. I am simply tossing out some food for thought. Also this may have been discussed at length before and put to rest. If so I apologize for bringing up dead topic. I'd be interested to know what was said though.</div>
<div><div><br></div><div>Zeke</div><div><br></div><div><br></div><div>--</div><div>Zeke Farwell</div><div>Burlington, VT, USA</div><div><br></div><div><br></div><div><br><br><div class="gmail_quote">On Sat, Sep 4, 2010 at 9:46 AM, Eric Jarvies <span dir="ltr"><<a href="mailto:eric@csl.com.mx">eric@csl.com.mx</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
On Sep 4, 2010, at 6:57 AM, Serge Wroclawski wrote:<br>
<br>
> On Sat, Sep 4, 2010 at 7:15 AM, Xan<br>
><br>
>> But, why don't you integrate the layers in OSM web page? Now we could choose<br>
>> Mapnik, Osmarender, ... why not put another possibility: "choose layer".<br>
>> Yeah!, I know it's a littble bit work (!) to do but it could be cool!. Very<br>
>> cool and (I think) useful....<br>
>><br>
>> Perhaps in talk-devel? ;-)<br>
><br>
> Xan,<br>
><br>
> You're right that this probably beyond the scope of the newbies list,<br>
> but let me ask you a question:<br>
><br>
> What is your use case?<br>
><br>
> If your use case is that what you want is a rendered layer for<br>
> displaying as a base map, that's a different matter then, say, wanting<br>
> a "layer" to be converted into a Shapefile and then imported into<br>
> another tool, and is yet distinct from "I just want to look at one<br>
> attribute in order to edit it" and is still yet distinct from "This<br>
> would be really cool".<br>
<br>
Having both would be nice. Being able to render raster tiles of each individual layer would be nice... as it would be nice to 'easily' output .osm(or .shp, etc.) files by key:value selections.<br>
<br>
Eric Jarvies<br>
<br>
><br>
> These are each different and I'd handle them differently, so knowing<br>
> what you're looking for will help all of us answer the question (even<br>
> if we stay on this list to do it).<br>
><br>
> - Serge<br>
><br>
> _______________________________________________<br>
> newbies mailing list<br>
> <a href="mailto:newbies@openstreetmap.org">newbies@openstreetmap.org</a><br>
> <a href="http://lists.openstreetmap.org/listinfo/newbies" target="_blank">http://lists.openstreetmap.org/listinfo/newbies</a><br>
><br>
<br>
<br>
_______________________________________________<br>
newbies mailing list<br>
<a href="mailto:newbies@openstreetmap.org">newbies@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/newbies" target="_blank">http://lists.openstreetmap.org/listinfo/newbies</a><br>
</blockquote></div><br></div></div>