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