Fawad, Caty, all,
Stéphane,
I will start off by learning Solr Search Query API and see how I can use it in
this application.
Great
One major concern is how we will be creating our maps. I introduced the idea of a map editor but now it seems that we will be using queries to generate our maps.
Imho we will need both. On the one hand, what you prototyped with map editors
will be useful for adding or editing data items – I foresee more one single
editor providing all the editing features than several distinct ones though,
what do you think? On the other hand, we will also use queries to generate maps
indeed.
What I have in mind after this is that the user will create an object of Map
class and then associate a query with it but I don't know how we will get the
relevant data for the map. For example if we want a point on the map, how would
we identify that we need that point. Do we have all the relevant objects on a
single page and then get all of them from that page to display those features
on the map?
I think we should start with having one page per object and that the query
defined at the Map object level will gather all the data to be displayed on the
map. Then, subqueries built on top of the primary one (adding full-text, facets
or spatial constraints) will let the user filter the existing elements. Having
one page per object will make it easy to associate content and images to each
geographical object: they will be the content and the attachments of the page
itself. What do you think? Having several objects attached to one page could be
useful as well in a second step I would say, for more advanced use cases
covering pages that relate to several distinct locations (e.g. a place that
consists of several points and splitted areas).
Can you give a reference to an application that is similar in structure to what we are striving for
in this application? I can't help but feel like this will lead to something of a "Map
Service" rather than a "Map Application". Sorry about all this confusion.
Here's a reference to an application that provides a user experience that is close to what I have
in mind, a sample map that I created on the GoGoCarto site: https://abc.gogocarto.fr/ (French
language again though). From there, hit the link "La carte" at the top right, then
"Ajouter un élément" (you can also get you an account for accessing the administration
user interface). You will see a form with a basic map editor for adding a point. It's close to my
view in the sense that it provides two distinct interfaces for 1) editing data, with a (basic) map
editor, 2) rendering the interactive map itself. From that perspective, we're more aiming at a map
renderer than at an advanced map editor, compared to what the XWiki diagram editor application is,
for instance. But we will still need an editor for editing individual points, shapes, paths, or
even a few of them combined, when editing a metro line for instance, but not a whole map at once.
Does this make the goal clearer and still meaningful to you? I would say imho
that we're aiming at a map application, since what users will produce or use is
an interactive map, but the application will hinge on an advanced map service
(or several ones) indeed. I feel like we're just aligning our views (I hope) on
a project with a certain level of complexity, I would not call that confusion!
Side note: later on in the development process and depending if it makes sense
for the XWiki product itself or not, we (the XWiki developer community at
large) could consider making points, shapes and paths primary XWiki property
types that could be used in any XWiki Class, so that the production of forms
comprising geographical data can be made even more simple, but we're not there
yet. This approach could be compared at least partly to what GeoDjango brings
to Django (I think): https://docs.djangoproject.com/en/2.2/ref/contrib/gis/
Maybe we can have a recorded video/audio conference as that will save us a lot
of time discussing these things. WDYT?
Sure, good idea, I'll send you some slot proposals to you and Caty.
Cheers
Stéphane
