What I will be doing now is create a Map class that can hold configuration properties. If these properties are filled then that data will be used while generating the map else some default configuration will be used. Maybe I will make a separate object for default configuration of the map?
Then once I am able to generate a map with the map class I will add a query based property to the map which will hold the query to what the map will have. A macro (maybe some other option?) will be made to handle the data gotten from the query. As we are focusing on a Point for now, I will make the macro so that if a Point object is queried, I will get all the properties of that particular point and add it to the map. For now I will only be querying objects on the same page to reduce complexity at an early stage. Is this a good approach for now or am I in the wrong direction? I really think we should have a detailed video conference since that will get us all on the same page and will take minimum time. Best, Fawad On Tue, May 28, 2019 at 8:30 PM Fawad Ali <m.fawaadal...@gmail.com> wrote: > 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 <slauri...@xwiki.com> > 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%20API >> >> 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 <slauri...@xwiki.com >> <mailto:slauri...@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 >> >>
