Feature feed with >1 placemark per Atom entry?

1 view
Skip to first unread message

pr

unread,
Aug 20, 2009, 1:15:59 PM8/20/09
to Google Maps Data API
According to the KML spec, "A Placemark is a Feature with associated
Geometry", which implies that a placemark is a type of feature and
consequently a feature cannot have more than one placemark. However,
in the HTTP protocol, under "KML Features" it says "Currently each
feature maps to one (and only one) <Placemark>" and further on "At
this time, the Maps Data API . . . does not support multiple
<Placemark> elements within one feature", which implies that at some
point in the future an atom entry in the features feed may contain
more than one placemark. This seems contradictory; should I assume
that an atom entry corresponds to one placemark or not? Or perhaps, to
put it the other way round, under what circumstances might an atom
entry contain more than one placemark?

pr

unread,
Oct 8, 2009, 5:22:17 AM10/8/09
to Google Maps Data API
nobody got any answer to this??

Bent

unread,
Oct 11, 2009, 1:45:32 PM10/11/09
to Google Maps Data API

On Aug 20, 10:15 am, pr <pw.rob...@googlemail.com> wrote:
> According to the KML spec, "A Placemark is a Feature with associated
> Geometry", which implies that a placemark is a type of feature

Yes, this is the KML standard.

> and
> consequently a feature cannot have more than one placemark.

In OO terms a KML <Placemark> is-a KML Feature.

> However,
> in the HTTP protocol,

Now on to a different subject: how the Google Maps Data API
carries KML Features.

> under "KML Features" it says "Currently each
> feature maps to one (and only one) <Placemark>" and further on "At
> this time, the Maps Data API . . . does not support multiple
> <Placemark> elements within one feature", which implies that at some
> point in the future an atom entry in the features feed may contain
> more than one placemark.

Personally I would not construe any current statements to be
any form of prediction of the future.

> This seems contradictory; should I assume
> that an atom entry corresponds to one placemark or not?

At present the Google Maps Data API carries exactly one KML Placemark
per <atom:entry> in the feature feed of a map.

> Or perhaps, to
> put it the other way round, under what circumstances might an atom
> entry contain more than one placemark?

None at present.

Why do you ask?

pr

unread,
Oct 12, 2009, 9:29:36 AM10/12/09
to Google Maps Data API
On Oct 11, 6:45 pm, Bent <kml.b...@gmail.com> wrote:
> Why do you ask?

I've submitted a patch to OpenLayers Atom class to enable it to handle
the Maps Data feeds, and it was pointed out to me that it would break
if Google do indeed start putting >1 placemark in an atom entry
http://trac.openlayers.org/ticket/1366#comment:20

I always prefer to try and clarify these things before implementing
them rather than have to redo them later

Bent Kml

unread,
Oct 29, 2009, 2:08:16 PM10/29/09
to google-map...@googlegroups.com
Generally I'd recomment defensive programming.  Accept what you understand and
ignore what you don't.  For example, <Placemark> is just one of the 8 Features
in KML.  That is, it _could_ come to be someday that the KML child of <atom:content>
might be one of <GroundOverlay>, <ScreenOverlay>, <NetworkLink>, etc...

Having multiple children of <atom:content> of any XML language strikes me as "funny",
but I don't offhand know what APP and/or Google Data generally have to say on that matter.
Reply all
Reply to author
Forward
0 new messages