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

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: 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. 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. application. 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?). 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. <mailto:slauriere@xwiki.com>> wrote: of the shapes on information someone about the multiple maps architecture)? 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. individual objects contain objects 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. 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? backgrounds), 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 Laurière XWiki – https://xwiki.com