[OSM-talk] Areas (was: Local map making - truncating ways on boundary?)

Karl Newman siliconfiend at gmail.com
Sat Apr 5 03:37:52 BST 2008


On Fri, Apr 4, 2008 at 7:02 PM, Frederik Ramm <frederik at remote.org> wrote:

> Hi,
>
>  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.
> >
>
> You are right in saying that not having an explicit polygon type makes OSM
> stick out from the standard OGC/ISO19100/whatever geometry models.
>
>     And the reason for the area type not there is because it has not been
> >    used when it was there.
> >
>
>  Really? I never knew OSM had a polygon type.
> >
>
> 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.
>
> We have the following options:
>
> 1. re-instate the "area" type during the next API update.
>
> 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.
>
> 3. create a script that takes the planet file and uploads an added
> "area=yes" to anything it considers an area.
>
> 4. modify the API to generate an "area=yes" tag on-the-fly whenever it
> returns a way whose tags make it an area.
>
> 5. live with what we've got.
>
> 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.
>
> Bye
> Frederik
>
>
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.

Thanks,

Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20080404/61507369/attachment.html>


More information about the talk mailing list