Use case (developer): Generate new vector features from data

[AmeliaBR]

This issue is for discussion of the use case “Generate new vector features from data”, its examples & list of required capabilities.

In the use case text, I've mentioned generating a vector shape from user drawing/selecting points on the map. It is therefore related to #18; I've kept this as a separate discussion so that that issue can instead focus on the basic case of extracting coordinates from a click on the map. (Which would be a prerequisite to using those coordinates to draw a new vector feature, of course.)

[prushforth]

I think there needs to be <input> types to support this capability. If a map document included a <form> containing such inputs, they could be activated by user interaction and provide capture of one or more locations as appropriate to the geometry type. Such inputs are common to Leaflet Draw and OpenLayers, for example, albeit not tied to declarative semantic elements.

In MapML, we have specified a <input type=location>, which I think could be subclassed to support input/capture of different geometry types.

[prushforth]

I see that you've linked to an issue and I've more or less repeated what I said there (sorry my bandwidth is very bad atm).

Anyway regarding the extraction of coordinates, we have to think about the coordinate transformations involved from click location in screen or viewport coordinates, to the coordinate system possibly requested by the author in markup.

The concept of a TCRS in MapML is intended to unify or provide a framework for such discussion, since the map as viewed by the user at a given moment must have a zoom / scale and bounds etc.

The concept of TCRS is very close to the concepts underlying WMTS, but with the client perspective foremost. The key characteristic of WMTS coordinate systems and therefore TCRS is that they match the axis orientations of computer graphics, with the origin at upper left, y-axis being positive downwards, and coordinate positions specified in (horizontal, vertical) (x,y) axis order. This is in contrast to TMS and many prominent geographic coordinate systems, which origin is at lower left, y is positive upwards and positions are specified in (latitude, longitude) axis order.

Accounting for or reconciling these different world views in a standard is a significant challenge, not only technically but perhaps even more critically from a communication standpoint.

In MapML, despite the wisdom of the test of independent invention, I gave up on integrating TMS, due to the difficulty of creating a coherent description of the coordinate systems involved, not because its technically impossible.

[prushforth]

Anyway, to come back to coordinate capture, Leaflet records the origin of the viewport of the map on zoomend, and then records and applies offsets to that location in pixels as the map is panned, so that it is able to calculate the location of a user event. It uses the scales of zoom levels to transform or untransform pixel based coordinates into projected coordinate system units, and can if requested use the CRS project and unproject methods to calculate geographic coordinates for the corresponding PCRS locations. The MapML polyfill leverages the code infrastructure of Leaflet and proj4Leaflet to manage these conversions using the equivalent TCRS concepts and terminology. I imagine similar processing could be done using any mapping library as backing, although the terminology would vary depending on the library. (Which will be a side benefit of standardisation - standard terms).