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
