The <feature> element was conceived as a semantic receiver for GeoJSON: the <properties> child would contain “regular”, styleable, linkable HTML that was intended as metadata for the feature, while the <geometry> element would contain OGC simple features geometries that have more semantic constraints than svg paths do (I think). We can discuss those constraints, but they’re related to real-world feature-ness I believe.
The GeoJSON model of arrays to describe these geometries has its own semantics, and the arrays can be transformed to SVG, WebGL, etc. by procedural logic (it is required actually). That’s great, because such procedural logic could also easily generate <geometry> values with very little change. However, I did not want to have the proposal rely exclusively on procedural logic to be supplied by Web sites.
In OGC testbed 15, we prototyped the rendering of MapML tiles, in which the geometries that were split by tile boundaries used <span class="noline"> ...</span>, so that in principle the sub-geometries that should not be drawn, or styled differently, could be targeted by CSS selectors. This worked quite well, except that the feature geometries had to be broken up and serialized as SVG paths with different DOM nodes representing the sub-parts, so that they could be targeted by CSS selectors.
That is a core reason: even though the HTML design principles say that not everything has to be modeled with deep semantic markup, we feel that targeting parts of geometries with CSS selectors is a very common need, even beyond the use case of hiding tile boundaries, and after the workshop, I feel it may have accessibility considerations as well.
So that is one reason to expose the geometry as semantic markup, but I think that future experiments could show that the best reason may be that geometries can encode links (<a href="..."></a>) in maps that can be used to federate map layers in the same way that HTML documents ‘federate’ web sites in a crawlable manner. And I also imagine that accessibility needs may demand the ability to mark up <geometry> parts without breaking the geometry integrity.
Finally, <geometry> as markup has been done before, in KML with some limited success and in GML with less success. Those two applications failed to deliver the styling and linking, and indeed the accessibility that I have mentioned above, mostly because they weren’t HTML, I think.
If you have a document that lists the reasons
There may be other good reasons, but I can’t think of them at this moment. I tried to make a thorough description of the proposal and it’s reasons here. It has taken some criticism for being too long already.
Second, Can you tell me why you need mapml instead of GeoJSON?
I think you mean <feature>, because <mapml> is proposed to be a document (root) element for the text/mapml media type, so that it can be referenced by <layer src="..."></layer> elements. So these are different things in the proposal. Please correct me if I’m wrong, but I answered what I thought the question was intended.
P.S. It seems to me that the map element and layer element specifications (section 4 2) can be considered as another specification separate from the mapml specification (section 5 2).
It used to be that way, but that was found to be an issue that complicated understanding the proposal as a whole, so we are moving towards a single specification at the current time. The intention is to eventually write the specification as a pull request to the WHATWG HTML specification, once we are ready with sufficient implementation experience, support, feedback etc.
