On Fri, Apr 4, 2008 at 7:02 PM, Frederik Ramm <<a href="mailto:frederik@remote.org">frederik@remote.org</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Yes, I meant to say if every *polygon* which is represented as a closed way was guaranteed to have an "area=yes" tag or some other distinguishing feature.<br>
</blockquote>
<br>
You are right in saying that not having an explicit polygon type makes OSM stick out from the standard OGC/ISO19100/whatever geometry models.<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
    And the reason for the area type not there is because it has not been<br>
    used when it was there.<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Really? I never knew OSM had a polygon type. <br>
</blockquote>
<br>
It was called "area" and was supported by API 0.3. I think it was in the API but not supported by JOSM and that's the reason nobody used it. The reason it wasn't supported in JOSM was probably a misunderstanding between SteveC and Imi, or at least that's what I've gathered. Remember, that was a time when software development in the project was driven by three or four people ,-) anyway, looking back doesn't help.<br>

<br>
We have the following options:<br>
<br>
1. re-instate the "area" type during the next API update.<br>
<br>
2. create an independent data source that maps a set of tags to a boolean "area" property. this data source might be a wiki page or SVN file that is read by the processing software, or might even be a web service. any software dealing with areas would use that service to know what makes an area and what doesn't.<br>

<br>
3. create a script that takes the planet file and uploads an added "area=yes" to anything it considers an area.<br>
<br>
4. modify the API to generate an "area=yes" tag on-the-fly whenever it returns a way whose tags make it an area.<br>
<br>
5. live with what we've got.<br>
<br>
As you say, option 5 is a bit sub-optimal because stuff has to be replicated everywhere. Personally I lean towards option 2; this would still require replication of the "check tags against list" logic in all applications but the list would come from a central source that's the same for wall. I think we have similar "shared configuration" things elsewhere and they seem to work.<br>

<br>
Bye<br><font color="#888888">
Frederik<br>
<br>
</font></blockquote></div><br>I would like option 1 but I could live with the others. The others seem like workarounds for poor structure, but that's the state of things now. Option 2 might be okay. Even better if it was wrapped up into a library (probably a few implementations in different languages) that various data consumers could use. Heck, I'm living with option 5 now, but as you said, it's sub-optimal.<br>
<br>Thanks,<br><br>Karl<br>