Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
AmeliaBR opened this issue Aug 10, 2019 · 3 comments
Open

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

AmeliaBR opened this issue Aug 10, 2019 · 3 comments
Labels
discussion: use case a possible use case: should it be included? what should it say? status: editor's draft there's a draft section in the report that corresponds to this discussion

Comments

@AmeliaBR
Copy link
Member

@AmeliaBR AmeliaBR commented Aug 10, 2019

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.)

@AmeliaBR AmeliaBR added discussion: use case a possible use case: should it be included? what should it say? status: editor's draft there's a draft section in the report that corresponds to this discussion labels Aug 10, 2019
@prushforth
Copy link
Member

@prushforth prushforth commented Aug 18, 2019

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
Copy link
Member

@prushforth prushforth commented Aug 18, 2019

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
Copy link
Member

@prushforth prushforth commented Aug 18, 2019

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion: use case a possible use case: should it be included? what should it say? status: editor's draft there's a draft section in the report that corresponds to this discussion
Projects
None yet
Development

No branches or pull requests

2 participants