Re: [xwiki-devs] Map Application - GSoC 19

Stéphane, I will start off by learning Solr Search Query API and see how I can use it in this application. 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. 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? 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. Maybe we can have a recorded video/audio conference as that will save us a lot of time discussing these things. WDYT? Best, Fawad On Tue, May 28, 2019 at 7:44 PM Stéphane Laurière &lt;slauriere(a)xwiki.com&gt; wrote: > Fawad, > > Thanks for your feedback. > > Regarding the data model: > > - Map: we clearly need a Map class :-). As discussed, it will hold the > map configuration, and possible links to sub-configurations (such as the > visual theme, to be discussed). Primarily, the map needs data, so it needs > a field for storing a query that will make it possible to retrieve data. > You certainly already found the Solr Query API documentation below, I > suggest you give it a try and read the basic query principles, then we can > set up dedicated examples together on real data in the next days. This > brings us to the question of real data. We will quickly need sample data to > work with, I think, I'm investigating how to download GeoJSON data from > OpenStreetMap, which itself contains links to Wikidata or Wikipedia, this > would allow us to grab some content and even images and to have a good > sample data set to work with. I'll keep you posted about that. > > > https://extensions.xwiki.org/xwiki/bin/view/Extension/Solr%20Search%20Query… > > In parallel, you could start thinking about the design and implementation > of the query endpoint that will return GeoJSON. Looking a bit into the code > of "Main.SolrSearchMacros" could be useful I would say, I'll think about it > as well. > > - Spatial entities : Point, Shape, Path, ...: I agree with you having one > XClass for each is probably the way to go, but I would suggest we start > just with "Point" and postpone the decision to a bit later if you agree, > just to make sure we don't make wrong assumptions and introduce too much > complexity (probably not, but to be discussed). Even the "icon" property > might be too early at this stage imho, because in real world scenarios I > believe it's more important to provide the ability to associate icons to > facets key/value pairs than to individual items. It may be useful in the > future, but we'll see, I would say. > > - Content: considering using content ids, or XPaths or XWiki DOM (XDOM) > queries could be quite powerful. We don't want the users to maintain > manually popup content, while they already have the burden to maintain the > main content itself. Using content ids / queries would avoid duplicating > content. This shares some concern with the Page Preview application, see > links below. I don't have a clear answer yet, we need to discuss a bit > further. But we could start with the first page paragraph for instance. > > > https://dev.xwiki.org/xwiki/bin/view/Drafts/Page%20Preview%20Application > https://xwiki.markmail.org/message/zhbaw7m3rsnbm26m?q=preview > https://github.com/xwiki-contrib/application-page-preview > > I'll be off in the next couple of hours but I'll provide more feedback as > soon as possible. > > Cheers > > Stéphane > > > Fawad Ali: > > Hi Stéphane and Ecaterina, > > > > Thanks for the update to the design page. It feels much more detailed > now imo. However it has left me confused with all the details. I was > focused on a more straightforward approach but we need to be more detailed > as I see it. > > > > I would like to know how I should move forward with what I have already > done. Considering the kind of structure Stephane suggests for the > application, we will have to redo it completely because I do not think what > I did so far is suitable for such requirements. > > > > Let me first discuss the data model since that will be the basis of the > application. > > We have the main entities as Map, Point, Shape, Path and Content. I > think it's better if we have an XClass for each of them with properties > that will highlight the available configurations for the entities. For > example, for the Point class, we can have properties icon, location, > content (may be an id from a content class object?). > > > > Also, I am not much familiar with Solr or any of the query languages in > XWiki since I was not going in that direction. I did try to look into Solr > quite a bit but it would help me a lot if you could provide me an example. > > > > And direction on how I move from here on out would also help a lot. > > > > Best, > > Fawad > > > > > > On Tue, May 28, 2019 at 6:14 PM Stéphane Laurière &lt;slauriere(a)xwiki.com > <mailto:slauriere@xwiki.com>> wrote: > > > > Hi Caty, Fawad, all, > > > > > > [...] > > > > > * I've read again the GSOC project description. The main purpose > of the > > > application is to allow multiple people to create POIs and other > shapes on > > > the Maps. There is a note that the POIs will have additional > information > > > about the location. > > > Some questions: > > > ** can a POI be displayed in multiple Maps? For example: if we > someone > > > creates a 'Centre Pompidou' POI in a page, where adds > information about the > > > place, images, etc. Should we be able to display this POI in > multiple maps > > > (one that contains museums, while others contain modern > architecture)? > > > > I would say it's important that a point of interest or any other > entity can be present in multiple maps indeed. A map is defined in > particular by a query imho – I would suggest a Solr query as argued on the > design page, what do you think? – which returns a set of elements. Then > the user can refine this set at will using full-text search, facets or > spatial search. > > > > > ** in any case, the POI storage could be done in objects or in > individual > > > pages. We need to think about performance too. Pages will lots > of objects > > > can have performance issues, so storing as pages (that will > contain objects > > > for POI type) might be better? > > > > Ideally that'd be great to support both options I would say. > > > > In terms of priority I would go for one object per page to start > with. Typically, in the encyclopedia use case defined in the design page, > having one object attached to each target page would be very convenient > imho: it would ease the maintenance of information, both textual and > geographical, related to each page. > > > > Supporting multiple objects per page could be quite useful as well. > Imagine for instance that we want to represent the "Battle of the Somme" on > a map. The content itself may refer to multiple locations (as on the > Wikipedia article below and its static image map representation), so it > could be handy to let the user input all these locations (points, areas, > lines...) as objects attached to the "Battle of the Somme" page itself > without the need to create individual pages for each location. There is no > reason to hit a very large number of objects in this scenario though. What > do you think? > > > > https://en.wikipedia.org/wiki/Battle_of_the_Somme > > > > > * Maps will also be pages, containing configuration (custom > backgrounds), > > > etc. > > > > Indeed, a map page will consist of a map configuration imho. We > need to define what is needed to configure a map, beside the query. The > visual configuration is important as well and can be possibly complex, and > other options could arise... > > > > Stéphane > > > > > > -- > > Stéphane Laurière > > XWiki – https://xwiki.com > > > > > -- > Stéphane Laurière > XWiki – https://xwiki.com > >