On Fri, Apr 4, 2008 at 7:02 PM, Frederik Ramm <[EMAIL PROTECTED]> 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
_______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
