Skip to content

Use Case: Recover what is drawn on the client by the user as (georeferenced) markup / feature objects #18

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

Open
prushforth opened this issue Apr 25, 2019 · 2 comments
Labels
discussion: use case a possible use case: should it be included? what should it say? status: suggestion this issue discusses a suggested addition to the report, that is not yet in the draft

Comments

@prushforth
Copy link
Member

Say we have a map, for which we provide a feature drawing API. The canvas on which that drawing occurs should be on the client, but it should be 'recoverable' as marked up features or even just plain GeoJSON, via a client API. To me, this suggests something like the following as a way to request user input:

<input type="location" subtype="point" (for example)>

Such an input would generate content on the map canvas with the assistance of the user. It might or might not be submitted, but the content could be recovered as georeferenced feature geometry content at least, perhaps via an API call on the map canvas, and perhaps also as an event from the input when user input was completed.

@prushforth prushforth changed the title Use Case: recover what is drawn on the client by the user as (georeferenced) markup / feature objects Use Case: Recover what is drawn on the client by the user as (georeferenced) markup / feature objects Apr 25, 2019
@cmhodgson
Copy link

Existing frameworks typically treat map drawing/editing tools as controls. Such editing controls work on editable layers, these layers could be either client side only, or you could allow editing of features retrieved from the server (as mapml vectors, or geojson?) The controls and/or layers provide event hooks that you connect into to perform more advanced functionality, eg. onChange, onCreate, etc. The layer in which the feature is created/edited would be used to access the feature objects.

@AmeliaBR
Copy link
Member

This sounds like a very broad use case, it might be worth breaking it down.

Focusing just on pin-point features, what you're asking is an API for using a map as an input for selecting a location. I think there are two ways I could see that working (which both have their use cases):

  • a form element <input type="location"> which works like a date picker or a color picker & triggers a browser-built pop-up that allows the user to select locations (maybe directly from a map, or from search, or from a list of saved locations that the browser has access to but the website doesn't). The website just gets the final location data (e.g., longitude & latitude). This all works completely separately from any maps drawn on the web page, although maybe you could associate it with custom map data in a manner similar to how you associate a text input with a <datalist> for auto-complete.

  • an API for translating a point on a web map (e.g., from a user click or from cursors controlled with arrow keys) to longitude & latitude data, so that a web author could write a custom location picker

Drawing shapes and paths and so on, is more complicated. I can't see that being a built-in feature to start, but it should definitely be a capability that an author could build from lower-level APIs, generating features point by point, and then exporting them in an interchangeable format.

@AmeliaBR AmeliaBR added discussion: use case a possible use case: should it be included? what should it say? status: suggestion this issue discusses a suggested addition to the report, that is not yet in the draft labels Apr 25, 2019
@AmeliaBR AmeliaBR added the section: client-side API Capabilities & use cases for client-side APIs label May 26, 2019
@AmeliaBR AmeliaBR removed the section: client-side API Capabilities & use cases for client-side APIs label Jul 25, 2019
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: suggestion this issue discusses a suggested addition to the report, that is not yet in the draft
Projects
None yet
Development

No branches or pull requests

3 participants