Map Application - GSoC 19

classic Classic list List threaded Threaded
133 messages Options
12345 ... 7
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Stéphane Laurière-6
Fawad,

> Hi,
> Hope all are doing well.
>
> Extremely thanks for the information Ecaterina. It really helps. :)
>
> I am trying to make filterable list maps but I am more or less stuck.
>
> This is what I have done so far:
> [image: image.png]
>
> So what I have in mind for this is that each marker will have a category
> and a custom popup. Then we can have custom marker image for each of the
> category or for each of the marker separately. I wanted to have forms
> directly inside the popup but that does not seem to be possible giving how
> popups in leaflet work.

I see at two distinct aspects there:

- How to associate a visual marker to a category or possibly to any attribute, conceptually

- Which user interface do we design and implement to help users define such associations

Imho, we have first to agree on the global mechanism to configure markers, then we'll think about the most appropriate user interface.

Introducing the concept of category is handy but I fear it could be quicly limited in real world scenarios, not sure. Take the encyclopedia use case, we have HLS at hand, here is a list of places referenced in HLS (by pure coincidence the end point is named "category" here, but the underlying mechanism is a Solr facet):

   https://hls-dhs-dss.ch/fr/search/category?f_hls.lexicofacet_string=1%2F006800.014300.

Imagine we want to represent these places on a map, with one icon per top level facet: political entity, ecclesiastical entity, environmnent, archeologia, etc. How can we specify that at the data model level? One option would be to introduce a mapping that associates pairs of Solr facet key, value to icons in the map configuration. We could have a large text field for that in the map configuration, what do you think? Another option would be to define a class for individual mappings, not sure it's needed though, a global text field might be enough, at least to begin with. Obviously this question hinges on the more general one about the query language we use to specify a set of entities to be represented on a map.

Regarding the user interface for configuring such associations, I have no clear proposal at this stage on my side, however I would suggest we validate the mechanism first, we implement it, and we consider making a visual configurator in a second step, what is your view on that? I agree it's not very handy to define such mappings as text, but on the other hand we gain in extensibility, and easing the configuration remains possible once the global use case is validated and accepted by real-world users (hopefully not far in future, in the frame of the GSoC itself if possible).

 
> This is a little afar from what I observe in
> https://napoleon-sainte-helene.plan-interactif.com and I am unable to think
> of a better way to manage everything.

Sorry, I don't understand well what's the scope of the comparison. Are you referring to the marker display, or the filters, or to the way markers can be configured, and if so, how did you access the marker configuration?

Cheers

Stéphane

> Stephane or Ecaterina, if you have a better approach and flow for this then
> please let me know.
> And Stephane, your help would be highly appreciable.
>
>
>
> Thanks. Best,
> Fawad


--
Stéphane Laurière
XWiki – https://xwiki.com

Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Fawad Ali
In reply to this post by Stéphane Laurière-6
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 <[hidden email]>
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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Stéphane Laurière-6
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 <[hidden email] <mailto:[hidden email]>> 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

Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Fawad Ali
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 <[hidden email]>
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 <[hidden email]
> <mailto:[hidden email]>> 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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Fawad Ali
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]
>> <mailto:[hidden email]>> 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
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Stéphane Laurière-6
In reply to this post by Fawad Ali
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




Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Stéphane Laurière-6
In reply to this post by Fawad Ali
Fawad, Caty, all,

A quick update following a video call I had with Fawad:

- The Solr API will be used to query the data to be displayed on the map, and the Solr facets to apply additional filters

- The data returned by the Solr API will be converted to GeoJSON. Later on we may consider creating a Solr service that returns (Geo)JSON directly rather than HTML, to be discussed.

Next steps:

- Creation of a basic Map class with a Solr query field

- Creation of a MapSheet that will render the map itself

- Creation of a Point class that will consist of one field storing the latitude and the longitude separated by a comma (later on, if needed, we will consider storing the latitude and the longitude in two distinct fields)

- Manual creation (or via the BatchImport application) of 1) a set of sample pages that will consist of: a title, some content, and a Point object attached to each page, 2) a Map object with a simple Solr query returning  all pages with a Point object in a specific space.

- Conversion of the the results provided by Solr into GeoJSON so that the data can be consumed and displayed by Leaflet

Fawad, please don't hesitate to mention any complementary aspect that I may have forgotten or questions you may have.

Cheers

Stéphane

Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Fawad Ali
Stéphane,

Thanks for this. It summarizes our discussions perfectly. :)
It's actually great that we are on the same page now. I will provide you
with updates soon.

Best,
Fawad


On Wed, May 29, 2019 at 4:34 PM Stéphane Laurière <[hidden email]>
wrote:

> Fawad, Caty, all,
>
> A quick update following a video call I had with Fawad:
>
> - The Solr API will be used to query the data to be displayed on the map,
> and the Solr facets to apply additional filters
>
> - The data returned by the Solr API will be converted to GeoJSON. Later on
> we may consider creating a Solr service that returns (Geo)JSON directly
> rather than HTML, to be discussed.
>
> Next steps:
>
> - Creation of a basic Map class with a Solr query field
>
> - Creation of a MapSheet that will render the map itself
>
> - Creation of a Point class that will consist of one field storing the
> latitude and the longitude separated by a comma (later on, if needed, we
> will consider storing the latitude and the longitude in two distinct fields)
>
> - Manual creation (or via the BatchImport application) of 1) a set of
> sample pages that will consist of: a title, some content, and a Point
> object attached to each page, 2) a Map object with a simple Solr query
> returning  all pages with a Point object in a specific space.
>
> - Conversion of the the results provided by Solr into GeoJSON so that the
> data can be consumed and displayed by Leaflet
>
> Fawad, please don't hesitate to mention any complementary aspect that I
> may have forgotten or questions you may have.
>
> Cheers
>
> Stéphane
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Fawad Ali
Hi Stéphane, Ecaterina and all,
Hope all of you are doing wonderful!

So I am working on the new iteration for the Interactive Maps Application
and have made some progress which I would like to share with all of you.
As suggested by Stephane, the application is now being developed on a new
architecture which emphasizes the use of Solr queries for gathering data to
display on the map. The space has also been changed to "Maps" as suggested
by Ecaterina.

Link:  https://github.com/9inpachi/interactive-maps-new
I have not shifted the files to xwiki-contrib because I wanted an initial
review if I am doing the right thing so I don't have to change the whole
repo twice.

I have been able to generate a map and the application is now able to
handle basic queries to include points (markers) inside the map.

I would like you to please give it a look and let me know if I am going in
the right direction. :)

Main application pages:
- Maps.Code.Map.MapClass => The main map class
- Maps.Code.Map.MapSheet => Map sheet that renders the map
- Maps.Code.Map.WebHome => Simple form for creating a map object page
- Maps.Code.Point.PointClass => Main class for a simple point (marker)
- Maps.Code.Leaflet => Page where all the javascript and stylesheet
extensions exist
- Maps.Code.CommonMacros => Some common macros used throughout the
application
- Maps.MapTesting => Space that contains objects and maps for testing

For adding a Point, create a simple page, add content to it and attach a
PointClass object with a value to it.

If you want to have a look at how the map is rendered, see the MapSheet and
the relevant jsx (leaflet-main) code on the Leaflet page.

I have attached some screenshots to show what the application does at this
point.

Best,
Fawad


On Wed, May 29, 2019 at 5:12 PM Fawad Ali <[hidden email]> wrote:

> Stéphane,
>
> Thanks for this. It summarizes our discussions perfectly. :)
> It's actually great that we are on the same page now. I will provide you
> with updates soon.
>
> Best,
> Fawad
>
>
> On Wed, May 29, 2019 at 4:34 PM Stéphane Laurière <[hidden email]>
> wrote:
>
>> Fawad, Caty, all,
>>
>> A quick update following a video call I had with Fawad:
>>
>> - The Solr API will be used to query the data to be displayed on the map,
>> and the Solr facets to apply additional filters
>>
>> - The data returned by the Solr API will be converted to GeoJSON. Later
>> on we may consider creating a Solr service that returns (Geo)JSON directly
>> rather than HTML, to be discussed.
>>
>> Next steps:
>>
>> - Creation of a basic Map class with a Solr query field
>>
>> - Creation of a MapSheet that will render the map itself
>>
>> - Creation of a Point class that will consist of one field storing the
>> latitude and the longitude separated by a comma (later on, if needed, we
>> will consider storing the latitude and the longitude in two distinct fields)
>>
>> - Manual creation (or via the BatchImport application) of 1) a set of
>> sample pages that will consist of: a title, some content, and a Point
>> object attached to each page, 2) a Map object with a simple Solr query
>> returning  all pages with a Point object in a specific space.
>>
>> - Conversion of the the results provided by Solr into GeoJSON so that the
>> data can be consumed and displayed by Leaflet
>>
>> Fawad, please don't hesitate to mention any complementary aspect that I
>> may have forgotten or questions you may have.
>>
>> Cheers
>>
>> Stéphane
>>
>>

page-with-point-object.png (19K) Download Attachment
map-object-creation.png (50K) Download Attachment
testmap-with-points.png (925K) Download Attachment
map-creation-form.png (20K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Stéphane Laurière-6
Hi Fawad, Caty, all,

Good to know where you are, Fawad. You're on the right track indeed imho, we're in tune.

I'm sending you below some feedback (part of it is code review that could take place directly on GitHub, but I feel it easier to discuss about it all together on the list for now, let's see how it goes, I'm open to any suggestion).

== MapClass and MapTemplate ==

- Query field: I'd suggest we use a large string field because the queries could become more complex in the future

- I would consider putting the default values directly in the template, so that the user can know what they are when he creates a map, what do you think?

- What about using an integer rather than a long for the zoom level?

- You probably already have this in mind: this will be handy to create a MapTemplateProvider as well, for example as indicated on <https://extensions.xwiki.org/xwiki/bin/view/Extension/Administration+Application#HCreatetheTemplateProvider>

== MapSheet ==

- Map creation: usually, class instances get created directly in the space of the application (see for instance the Diagram application), I would suggest we do the same here if that's ok with you, i.e. directly in the Map space, for maps and for points as well. As for test data: we will need to store test data indeed without the need to recreate it manually everytime, I'm adding an item about that in the "Next steps" section below.

- Currently, the sheet issues a call to com.xpn.xwiki.api.Object:getXWikiObject. This method requires programming rights. Most of the classes in package com.xpn.xwiki.api give access to their wrapped core object only to users with programming rights, since it allows to manipulate the data at a low level. I'm adding some links below that may help you understand this aspect (you may know them already). Another option (the one I favour) is to always have the xwiki-platform source code at hand in the IDE, so that one can check what the API does exactly. In an XWiki sheet, we typically don't want the programming right to be required, because sheets are meant to be customized by users, not necessarily by administrators. You will hence have to generate the target JSON without resorting to the wrapped BaseObject.

  https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/Scripting/
  http://nexus.xwiki.org/nexus/service/local/repositories/public/archive/org/xwiki/platform/xwiki-platform-oldcore/11.3/xwiki-platform-oldcore-11.3-javadoc.jar/!/index.html

- I'm wondering if it's necessary to generate a random id for the map container: couldn't we simply use the lower-case serialized map reference?

== CommonMacros ==

Yes, the "handleMapQuery" macro is in the right direction.

== Global code organization ==

- Currently the code uses one space per class. That's an option indeed, but it seems to me that the usual practice is more to group all classes and sheets directly in the "Code" space. See for instance the blog application: https://github.com/xwiki-contrib/application-blog/tree/master/application-blog-ui/src/main/resources/Blog. What do you think Caty, all?

- We're currently using the "Maps" space. I know the plural was discussed for the app name already, I have no further comment about that. In existing XWiki applications, we use either the singular or the plural for the application space. For instance, the following apps use the singular: application-diagram, application-xpoll, application-meeting, batchimport, application-forum, application-flashmessages (plural in the application name, singular in the space name in this case). Other use plural everywhere: application-invoices, application-ideas. Question to Caty and to all: do we have guidelines for that? This is a minor issue but I have a slight preference for using the singular in the space name, since to me it refers primarily to the application itself, not necessarily to the location where the target instances will be created. Typically, maps could be created anywhere in the wiki. The map app code, though, will be stored in that space. Sorry for being picky, I just want to make sure we all agree on the final name before a potential refactoring becomes more complex.

== Next steps ==

You probably have several of the next steps if not all in mind already, I'm listing some of them below so that we make sure to converge and decide:

- Add a livetable listing all existing maps, in the "WebHome" page of the top level application space

- Display page titles in the popups

- Find a way to plug the query mechanism to the Main.SolrSearch and Main.SolrSearchMacros (so that we can then use facets). This can be a bit tricky, let us know if you need help of course, for this aspect or any other.

- Add a full-text input widget to the map that will issue Solr queries asynchronously to the map query service (example: the user inputs "archeologia" -> only pages matching that word will get returned, and only the corresponding points will show up on the map), which will return the documents matching the initial query completed by the added full-text constraint.

- Add a contextual paginated list of results.

- Add facet filters.

- Test data: for now, we have just a few points to test with, but in the near future we will need one or several rich data sets samples to test the application. I'm not sure whether we should put the data and the code to create it in the same repository as the application itself or if we should create a dedicated repository. Typically, I foresee some code that will fetch some data from Wikidata or OpenStreetMap and convert it to several hundreds or thousands of XWiki pages, which in turn will be consumed by a map. Example: the query below executed against the endpoint https://query.wikidata.org/ will return all the museums referenced in Wikidata with their name, their geographical coordinates and their country. We could grab the museum JSON representations and turn them into XWiki pages (I have some code for doing such operations in another context already, I will commit it soon). I'm wondering if we store the test data and code in the same repository (this can amount to hundreds of test pages), or in a distinct one. I'll send a separate question to the list about this aspect.

   SELECT ?item ?itemLabel ?coord ?lon ?lat ?country ?countryLabel WHERE {
    ?item wdt:P17 ?country.
    ?item wdt:P31 wd:Q33506.   # is a museum
    ?item p:P625 ?coordinate.
    ?coordinate ps:P625 ?coord.
    ?coordinate psv:P625 ?coordinate_node.
    ?coordinate_node wikibase:geoLongitude ?lon.
    ?coordinate_node wikibase:geoLatitude ?lat.
    SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
   }

- Regarding paths: I saw you mentioned them on #xwiki, that will be an important feature indeed but I feel like it's more important to make sure that we have a working prototype consisting of a map, a search input, a list and facets with points already, before adding more complex objects to the map, what do you think?

Cheers

Stéphane


Fawad Ali:

> Hi Stéphane, Ecaterina and all,
> Hope all of you are doing wonderful!
>
> So I am working on the new iteration for the Interactive Maps Application and have made some progress which I would like to share with all of you.
> As suggested by Stephane, the application is now being developed on a new architecture which emphasizes the use of Solr queries for gathering data to display on the map. The space has also been changed to "Maps" as suggested by Ecaterina.
>
> Link: https://github.com/9inpachi/interactive-maps-new
> I have not shifted the files to xwiki-contrib because I wanted an initial review if I am doing the right thing so I don't have to change the whole repo twice.
>
> I have been able to generate a map and the application is now able to handle basic queries to include points (markers) inside the map.
>
> I would like you to please give it a look and let me know if I am going in the right direction. :)
>
> Main application pages:
> - Maps.Code.Map.MapClass => The main map class
> - Maps.Code.Map.MapSheet => Map sheet that renders the map
> - Maps.Code.Map.WebHome => Simple form for creating a map object page
> - Maps.Code.Point.PointClass => Main class for a simple point (marker)
> - Maps.Code.Leaflet => Page where all the javascript and stylesheet extensions exist
> - Maps.Code.CommonMacros => Some common macros used throughout the application
> - Maps.MapTesting => Space that contains objects and maps for testing
>
> For adding a Point, create a simple page, add content to it and attach a PointClass object with a value to it.
>
> If you want to have a look at how the map is rendered, see the MapSheet and the relevant jsx (leaflet-main) code on the Leaflet page.
>
> I have attached some screenshots to show what the application does at this point.
>
> Best,
> Fawad
>
>
> On Wed, May 29, 2019 at 5:12 PM Fawad Ali <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Stéphane,
>
>     Thanks for this. It summarizes our discussions perfectly. :)
>     It's actually great that we are on the same page now. I will provide you with updates soon.
>
>     Best,
>     Fawad
>
>
>     On Wed, May 29, 2019 at 4:34 PM Stéphane Laurière <[hidden email] <mailto:[hidden email]>> wrote:
>
>         Fawad, Caty, all,
>
>         A quick update following a video call I had with Fawad:
>
>         - The Solr API will be used to query the data to be displayed on the map, and the Solr facets to apply additional filters
>
>         - The data returned by the Solr API will be converted to GeoJSON. Later on we may consider creating a Solr service that returns (Geo)JSON directly rather than HTML, to be discussed.
>
>         Next steps:
>
>         - Creation of a basic Map class with a Solr query field
>
>         - Creation of a MapSheet that will render the map itself
>
>         - Creation of a Point class that will consist of one field storing the latitude and the longitude separated by a comma (later on, if needed, we will consider storing the latitude and the longitude in two distinct fields)
>
>         - Manual creation (or via the BatchImport application) of 1) a set of sample pages that will consist of: a title, some content, and a Point object attached to each page, 2) a Map object with a simple Solr query returning  all pages with a Point object in a specific space.
>
>         - Conversion of the the results provided by Solr into GeoJSON so that the data can be consumed and displayed by Leaflet
>
>         Fawad, please don't hesitate to mention any complementary aspect that I may have forgotten or questions you may have.
>
>         Cheers
>
>         Stéphane
>


--
Stéphane Laurière
XWiki – https://xwiki.com

Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Fawad Ali
Hi all,

Thanks for the detailed review, Stephane. I have made the changes you
suggested with some next steps also done.

Furthermore, I will make changes to the application space once we have
confirmed response from Caty or other developers.
I have started to work on the other next steps and will provide with
updates soon.

The original github repo is also updated, so future updates will be
available at https://github.com/xwiki-contrib/application-interactive-maps
.

Thanks,
Fawad


On Mon, Jun 3, 2019 at 12:38 PM Stéphane Laurière <[hidden email]>
wrote:

> Hi Fawad, Caty, all,
>
> Good to know where you are, Fawad. You're on the right track indeed imho,
> we're in tune.
>
> I'm sending you below some feedback (part of it is code review that could
> take place directly on GitHub, but I feel it easier to discuss about it all
> together on the list for now, let's see how it goes, I'm open to any
> suggestion).
>
> == MapClass and MapTemplate ==
>
> - Query field: I'd suggest we use a large string field because the queries
> could become more complex in the future
>
> - I would consider putting the default values directly in the template, so
> that the user can know what they are when he creates a map, what do you
> think?
>
> - What about using an integer rather than a long for the zoom level?
>
> - You probably already have this in mind: this will be handy to create a
> MapTemplateProvider as well, for example as indicated on <
> https://extensions.xwiki.org/xwiki/bin/view/Extension/Administration+Application#HCreatetheTemplateProvider
> >
>
> == MapSheet ==
>
> - Map creation: usually, class instances get created directly in the space
> of the application (see for instance the Diagram application), I would
> suggest we do the same here if that's ok with you, i.e. directly in the Map
> space, for maps and for points as well. As for test data: we will need to
> store test data indeed without the need to recreate it manually everytime,
> I'm adding an item about that in the "Next steps" section below.
>
> - Currently, the sheet issues a call to
> com.xpn.xwiki.api.Object:getXWikiObject. This method requires programming
> rights. Most of the classes in package com.xpn.xwiki.api give access to
> their wrapped core object only to users with programming rights, since it
> allows to manipulate the data at a low level. I'm adding some links below
> that may help you understand this aspect (you may know them already).
> Another option (the one I favour) is to always have the xwiki-platform
> source code at hand in the IDE, so that one can check what the API does
> exactly. In an XWiki sheet, we typically don't want the programming right
> to be required, because sheets are meant to be customized by users, not
> necessarily by administrators. You will hence have to generate the target
> JSON without resorting to the wrapped BaseObject.
>
>   https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/Scripting/
>
> http://nexus.xwiki.org/nexus/service/local/repositories/public/archive/org/xwiki/platform/xwiki-platform-oldcore/11.3/xwiki-platform-oldcore-11.3-javadoc.jar/!/index.html
>
> - I'm wondering if it's necessary to generate a random id for the map
> container: couldn't we simply use the lower-case serialized map reference?
>
> == CommonMacros ==
>
> Yes, the "handleMapQuery" macro is in the right direction.
>
> == Global code organization ==
>
> - Currently the code uses one space per class. That's an option indeed,
> but it seems to me that the usual practice is more to group all classes and
> sheets directly in the "Code" space. See for instance the blog application:
> https://github.com/xwiki-contrib/application-blog/tree/master/application-blog-ui/src/main/resources/Blog.
> What do you think Caty, all?
>
> - We're currently using the "Maps" space. I know the plural was discussed
> for the app name already, I have no further comment about that. In existing
> XWiki applications, we use either the singular or the plural for the
> application space. For instance, the following apps use the singular:
> application-diagram, application-xpoll, application-meeting, batchimport,
> application-forum, application-flashmessages (plural in the application
> name, singular in the space name in this case). Other use plural
> everywhere: application-invoices, application-ideas. Question to Caty and
> to all: do we have guidelines for that? This is a minor issue but I have a
> slight preference for using the singular in the space name, since to me it
> refers primarily to the application itself, not necessarily to the location
> where the target instances will be created. Typically, maps could be
> created anywhere in the wiki. The map app code, though, will be stored in
> that space. Sorry for being picky, I just want to make sure we all agree on
> the final name before a potential refactoring becomes more complex.
>
> == Next steps ==
>
> You probably have several of the next steps if not all in mind already,
> I'm listing some of them below so that we make sure to converge and decide:
>
> - Add a livetable listing all existing maps, in the "WebHome" page of the
> top level application space
>
> - Display page titles in the popups
>
> - Find a way to plug the query mechanism to the Main.SolrSearch and
> Main.SolrSearchMacros (so that we can then use facets). This can be a bit
> tricky, let us know if you need help of course, for this aspect or any
> other.
>
> - Add a full-text input widget to the map that will issue Solr queries
> asynchronously to the map query service (example: the user inputs
> "archeologia" -> only pages matching that word will get returned, and only
> the corresponding points will show up on the map), which will return the
> documents matching the initial query completed by the added full-text
> constraint.
>
> - Add a contextual paginated list of results.
>
> - Add facet filters.
>
> - Test data: for now, we have just a few points to test with, but in the
> near future we will need one or several rich data sets samples to test the
> application. I'm not sure whether we should put the data and the code to
> create it in the same repository as the application itself or if we should
> create a dedicated repository. Typically, I foresee some code that will
> fetch some data from Wikidata or OpenStreetMap and convert it to several
> hundreds or thousands of XWiki pages, which in turn will be consumed by a
> map. Example: the query below executed against the endpoint
> https://query.wikidata.org/ will return all the museums referenced in
> Wikidata with their name, their geographical coordinates and their country.
> We could grab the museum JSON representations and turn them into XWiki
> pages (I have some code for doing such operations in another context
> already, I will commit it soon). I'm wondering if we store the test data
> and code in the same repository (this can amount to hundreds of test
> pages), or in a distinct one. I'll send a separate question to the list
> about this aspect.
>
>    SELECT ?item ?itemLabel ?coord ?lon ?lat ?country ?countryLabel WHERE {
>     ?item wdt:P17 ?country.
>     ?item wdt:P31 wd:Q33506.   # is a museum
>     ?item p:P625 ?coordinate.
>     ?coordinate ps:P625 ?coord.
>     ?coordinate psv:P625 ?coordinate_node.
>     ?coordinate_node wikibase:geoLongitude ?lon.
>     ?coordinate_node wikibase:geoLatitude ?lat.
>     SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
>    }
>
> - Regarding paths: I saw you mentioned them on #xwiki, that will be an
> important feature indeed but I feel like it's more important to make sure
> that we have a working prototype consisting of a map, a search input, a
> list and facets with points already, before adding more complex objects to
> the map, what do you think?
>
> Cheers
>
> Stéphane
>
>
> Fawad Ali:
> > Hi Stéphane, Ecaterina and all,
> > Hope all of you are doing wonderful!
> >
> > So I am working on the new iteration for the Interactive Maps
> Application and have made some progress which I would like to share with
> all of you.
> > As suggested by Stephane, the application is now being developed on a
> new architecture which emphasizes the use of Solr queries for gathering
> data to display on the map. The space has also been changed to "Maps" as
> suggested by Ecaterina.
> >
> > Link: https://github.com/9inpachi/interactive-maps-new
> > I have not shifted the files to xwiki-contrib because I wanted an
> initial review if I am doing the right thing so I don't have to change the
> whole repo twice.
> >
> > I have been able to generate a map and the application is now able to
> handle basic queries to include points (markers) inside the map.
> >
> > I would like you to please give it a look and let me know if I am going
> in the right direction. :)
> >
> > Main application pages:
> > - Maps.Code.Map.MapClass => The main map class
> > - Maps.Code.Map.MapSheet => Map sheet that renders the map
> > - Maps.Code.Map.WebHome => Simple form for creating a map object page
> > - Maps.Code.Point.PointClass => Main class for a simple point (marker)
> > - Maps.Code.Leaflet => Page where all the javascript and stylesheet
> extensions exist
> > - Maps.Code.CommonMacros => Some common macros used throughout the
> application
> > - Maps.MapTesting => Space that contains objects and maps for testing
> >
> > For adding a Point, create a simple page, add content to it and attach a
> PointClass object with a value to it.
> >
> > If you want to have a look at how the map is rendered, see the MapSheet
> and the relevant jsx (leaflet-main) code on the Leaflet page.
> >
> > I have attached some screenshots to show what the application does at
> this point.
> >
> > Best,
> > Fawad
> >
> >
> > On Wed, May 29, 2019 at 5:12 PM Fawad Ali <[hidden email]
> <mailto:[hidden email]>> wrote:
> >
> >     Stéphane,
> >
> >     Thanks for this. It summarizes our discussions perfectly. :)
> >     It's actually great that we are on the same page now. I will provide
> you with updates soon.
> >
> >     Best,
> >     Fawad
> >
> >
> >     On Wed, May 29, 2019 at 4:34 PM Stéphane Laurière <
> [hidden email] <mailto:[hidden email]>> wrote:
> >
> >         Fawad, Caty, all,
> >
> >         A quick update following a video call I had with Fawad:
> >
> >         - The Solr API will be used to query the data to be displayed on
> the map, and the Solr facets to apply additional filters
> >
> >         - The data returned by the Solr API will be converted to
> GeoJSON. Later on we may consider creating a Solr service that returns
> (Geo)JSON directly rather than HTML, to be discussed.
> >
> >         Next steps:
> >
> >         - Creation of a basic Map class with a Solr query field
> >
> >         - Creation of a MapSheet that will render the map itself
> >
> >         - Creation of a Point class that will consist of one field
> storing the latitude and the longitude separated by a comma (later on, if
> needed, we will consider storing the latitude and the longitude in two
> distinct fields)
> >
> >         - Manual creation (or via the BatchImport application) of 1) a
> set of sample pages that will consist of: a title, some content, and a
> Point object attached to each page, 2) a Map object with a simple Solr
> query returning  all pages with a Point object in a specific space.
> >
> >         - Conversion of the the results provided by Solr into GeoJSON so
> that the data can be consumed and displayed by Leaflet
> >
> >         Fawad, please don't hesitate to mention any complementary aspect
> that I may have forgotten or questions you may have.
> >
> >         Cheers
> >
> >         Stéphane
> >
>
>
> --
> Stéphane Laurière
> XWiki – https://xwiki.com
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Stéphane Laurière-6
Fawad, Thanks for letting us know, I could install the new app version, I confirm that all the changes you added to the progress file (very handy) work for me, and the refactoring is ok. I noticed a minor issue that you're certainly aware of already: it seems there's a small offset between the custom marker position (with the Islamabad point) and the popup position.

Talk to you soon,

Stéphane


Fawad Ali:

> Hi all,
>
> Thanks for the detailed review, Stephane. I have made the changes you suggested with some next steps also done.
>
> Furthermore, I will make changes to the application space once we have confirmed response from Caty or other developers.
> I have started to work on the other next steps and will provide with updates soon.
>
> The original github repo is also updated, so future updates will be available at https://github.com/xwiki-contrib/application-interactive-maps.
>
> Thanks,
> Fawad


--
Stéphane Laurière
XWiki – https://xwiki.com


Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Fawad Ali
Hi Stephane, Caty and all,
Hope you are doing fine.

I am glad you brought up the topic of custom marker icon. I am well aware
of the issue. Actually there are two problems with custom markers.
- The icon offset
- The document attachment

For the icon offset, when I tried to fix it initially it seemed that I can
overcome the offset either by height or width which means that the offset
still exists from a single side so I had that postponed since I thought
solr query tasks take priority.

For the attachment, for now I am getting the first attachment (0th index)
from the Point page which is not very reliable. For example if we have
images on the page, it could be that the marker takes one of the
attachments even if the user did not want a custom icon or an image
different from what the user wanted to choose is selected as the marker
icon.

What I have in mind is that we define categories for marker icons
dynamically.
We could make a separate dedicated page "MarkerIcons" and attach multiple
images to it. Then these images could appear in a list as one of the
properties in the Point object where we can choose the icon from. WDYT?

Thanks,
Fawad

On Tue, Jun 4, 2019, 11:31 AM Stéphane Laurière <[hidden email] wrote:

> Fawad, Thanks for letting us know, I could install the new app version, I
> confirm that all the changes you added to the progress file (very handy)
> work for me, and the refactoring is ok. I noticed a minor issue that you're
> certainly aware of already: it seems there's a small offset between the
> custom marker position (with the Islamabad point) and the popup position.
>
> Talk to you soon,
>
> Stéphane
>
>
> Fawad Ali:
> > Hi all,
> >
> > Thanks for the detailed review, Stephane. I have made the changes you
> suggested with some next steps also done.
> >
> > Furthermore, I will make changes to the application space once we have
> confirmed response from Caty or other developers.
> > I have started to work on the other next steps and will provide with
> updates soon.
> >
> > The original github repo is also updated, so future updates will be
> available at https://github.com/xwiki-contrib/application-interactive-maps
> .
> >
> > Thanks,
> > Fawad
>
>
> --
> Stéphane Laurière
> XWiki – https://xwiki.com
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Fawad Ali
Also, I forgot to mention it before but we will need a better and more
expressive way to show popups. We need something that can accomodate
sufficient amount of text with a scroll if the information exceeds the page.
I will prepare a mockup for this once I am done with some of the next steps.

And I think we should use the colortheme colors for our map controls and
consequently for the popups. I will update you on that as well.

Best,
Fawad


On Tue, Jun 4, 2019 at 3:31 PM Fawad Ali <[hidden email]> wrote:

> Hi Stephane, Caty and all,
> Hope you are doing fine.
>
> I am glad you brought up the topic of custom marker icon. I am well aware
> of the issue. Actually there are two problems with custom markers.
> - The icon offset
> - The document attachment
>
> For the icon offset, when I tried to fix it initially it seemed that I can
> overcome the offset either by height or width which means that the offset
> still exists from a single side so I had that postponed since I thought
> solr query tasks take priority.
>
> For the attachment, for now I am getting the first attachment (0th index)
> from the Point page which is not very reliable. For example if we have
> images on the page, it could be that the marker takes one of the
> attachments even if the user did not want a custom icon or an image
> different from what the user wanted to choose is selected as the marker
> icon.
>
> What I have in mind is that we define categories for marker icons
> dynamically.
> We could make a separate dedicated page "MarkerIcons" and attach multiple
> images to it. Then these images could appear in a list as one of the
> properties in the Point object where we can choose the icon from. WDYT?
>
> Thanks,
> Fawad
>
> On Tue, Jun 4, 2019, 11:31 AM Stéphane Laurière <[hidden email]
> wrote:
>
>> Fawad, Thanks for letting us know, I could install the new app version, I
>> confirm that all the changes you added to the progress file (very handy)
>> work for me, and the refactoring is ok. I noticed a minor issue that you're
>> certainly aware of already: it seems there's a small offset between the
>> custom marker position (with the Islamabad point) and the popup position.
>>
>> Talk to you soon,
>>
>> Stéphane
>>
>>
>> Fawad Ali:
>> > Hi all,
>> >
>> > Thanks for the detailed review, Stephane. I have made the changes you
>> suggested with some next steps also done.
>> >
>> > Furthermore, I will make changes to the application space once we have
>> confirmed response from Caty or other developers.
>> > I have started to work on the other next steps and will provide with
>> updates soon.
>> >
>> > The original github repo is also updated, so future updates will be
>> available at
>> https://github.com/xwiki-contrib/application-interactive-maps.
>> >
>> > Thanks,
>> > Fawad
>>
>>
>> --
>> Stéphane Laurière
>> XWiki – https://xwiki.com
>>
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Ecaterina Moraru (Valica)
Hi,

Some notes:
- We don't have guidelines regarding the singular / plural thing. I'm glad
that on the new sources we don't have the Maps/Map anymore. I'm fine with
Maps. In practice we have a mix of singular (like Diagram, Calendar,
Meeting) and plural (like Ideas, Forums). I prefer the plural version,
although in practice I think we have more with singular. There was a
tentative old draft for having such guidelines
https://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationGuidelines  but
we didn't worked on it for some time.

- Regarding the new Git repository. Since you've committed the initial
commits in issues, you should do a release with the initial version, and
than just release a new version for the interactive-maps-new . It's normal
in an application's development flow that changes happen, that's why
versioning schemes are all about.

- I still have the error I've mentioned before :
Uncaught Error: Script error for "leaflet", needed by: leafletSearch
http://requirejs.org/docs/errors.html#scripterror
    at F (require.min.js?r=1:7)
    at HTMLScriptElement.onScriptError (require.min.js?r=1:30)

leaflet.css:1 Failed to load resource: the server responded with a status
of 404 (Not Found)

so I cannot actually test the build, since I don't see the maps. I have
this both on Chrome and Firefox. Do I need to do something?

Thanks,
Caty

On Tue, Jun 4, 2019 at 2:31 PM Fawad Ali <[hidden email]> wrote:

> Also, I forgot to mention it before but we will need a better and more
> expressive way to show popups. We need something that can accomodate
> sufficient amount of text with a scroll if the information exceeds the page.
> I will prepare a mockup for this once I am done with some of the next
> steps.
>
> And I think we should use the colortheme colors for our map controls and
> consequently for the popups. I will update you on that as well.
>
> Best,
> Fawad
>
>
> On Tue, Jun 4, 2019 at 3:31 PM Fawad Ali <[hidden email]> wrote:
>
>> Hi Stephane, Caty and all,
>> Hope you are doing fine.
>>
>> I am glad you brought up the topic of custom marker icon. I am well aware
>> of the issue. Actually there are two problems with custom markers.
>> - The icon offset
>> - The document attachment
>>
>> For the icon offset, when I tried to fix it initially it seemed that I
>> can overcome the offset either by height or width which means that the
>> offset still exists from a single side so I had that postponed since I
>> thought solr query tasks take priority.
>>
>> For the attachment, for now I am getting the first attachment (0th index)
>> from the Point page which is not very reliable. For example if we have
>> images on the page, it could be that the marker takes one of the
>> attachments even if the user did not want a custom icon or an image
>> different from what the user wanted to choose is selected as the marker
>> icon.
>>
>> What I have in mind is that we define categories for marker icons
>> dynamically.
>> We could make a separate dedicated page "MarkerIcons" and attach multiple
>> images to it. Then these images could appear in a list as one of the
>> properties in the Point object where we can choose the icon from. WDYT?
>>
>> Thanks,
>> Fawad
>>
>> On Tue, Jun 4, 2019, 11:31 AM Stéphane Laurière <[hidden email]
>> wrote:
>>
>>> Fawad, Thanks for letting us know, I could install the new app version,
>>> I confirm that all the changes you added to the progress file (very handy)
>>> work for me, and the refactoring is ok. I noticed a minor issue that you're
>>> certainly aware of already: it seems there's a small offset between the
>>> custom marker position (with the Islamabad point) and the popup position.
>>>
>>> Talk to you soon,
>>>
>>> Stéphane
>>>
>>>
>>> Fawad Ali:
>>> > Hi all,
>>> >
>>> > Thanks for the detailed review, Stephane. I have made the changes you
>>> suggested with some next steps also done.
>>> >
>>> > Furthermore, I will make changes to the application space once we have
>>> confirmed response from Caty or other developers.
>>> > I have started to work on the other next steps and will provide with
>>> updates soon.
>>> >
>>> > The original github repo is also updated, so future updates will be
>>> available at
>>> https://github.com/xwiki-contrib/application-interactive-maps.
>>> >
>>> > Thanks,
>>> > Fawad
>>>
>>>
>>> --
>>> Stéphane Laurière
>>> XWiki – https://xwiki.com
>>>
>>>
>>>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Fawad Ali
Hi,

Caty, do you have the error with the latest git repo as well?
Actually the leaflet-commons require leaflet but the functions are not
actually called anywhere without the leaflet dependency used in require.

There is no error on my or Stephane side.
I have the 11.3-rc version of XWiki.
You can try Ctrl+F5 for a complete new load of the resources.

Best,
Fawad

On Wed, Jun 5, 2019, 10:22 PM Ecaterina Moraru (Valica) <[hidden email]
wrote:

> Hi,
>
> Some notes:
> - We don't have guidelines regarding the singular / plural thing. I'm glad
> that on the new sources we don't have the Maps/Map anymore. I'm fine with
> Maps. In practice we have a mix of singular (like Diagram, Calendar,
> Meeting) and plural (like Ideas, Forums). I prefer the plural version,
> although in practice I think we have more with singular. There was a
> tentative old draft for having such guidelines
> https://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationGuidelines
> but we didn't worked on it for some time.
>
> - Regarding the new Git repository. Since you've committed the initial
> commits in issues, you should do a release with the initial version, and
> than just release a new version for the interactive-maps-new . It's normal
> in an application's development flow that changes happen, that's why
> versioning schemes are all about.
>
> - I still have the error I've mentioned before :
> Uncaught Error: Script error for "leaflet", needed by: leafletSearch
> http://requirejs.org/docs/errors.html#scripterror
>     at F (require.min.js?r=1:7)
>     at HTMLScriptElement.onScriptError (require.min.js?r=1:30)
>
> leaflet.css:1 Failed to load resource: the server responded with a status
> of 404 (Not Found)
>
> so I cannot actually test the build, since I don't see the maps. I have
> this both on Chrome and Firefox. Do I need to do something?
>
> Thanks,
> Caty
>
> On Tue, Jun 4, 2019 at 2:31 PM Fawad Ali <[hidden email]> wrote:
>
>> Also, I forgot to mention it before but we will need a better and more
>> expressive way to show popups. We need something that can accomodate
>> sufficient amount of text with a scroll if the information exceeds the page.
>> I will prepare a mockup for this once I am done with some of the next
>> steps.
>>
>> And I think we should use the colortheme colors for our map controls and
>> consequently for the popups. I will update you on that as well.
>>
>> Best,
>> Fawad
>>
>>
>> On Tue, Jun 4, 2019 at 3:31 PM Fawad Ali <[hidden email]> wrote:
>>
>>> Hi Stephane, Caty and all,
>>> Hope you are doing fine.
>>>
>>> I am glad you brought up the topic of custom marker icon. I am well
>>> aware of the issue. Actually there are two problems with custom markers.
>>> - The icon offset
>>> - The document attachment
>>>
>>> For the icon offset, when I tried to fix it initially it seemed that I
>>> can overcome the offset either by height or width which means that the
>>> offset still exists from a single side so I had that postponed since I
>>> thought solr query tasks take priority.
>>>
>>> For the attachment, for now I am getting the first attachment (0th
>>> index) from the Point page which is not very reliable. For example if we
>>> have images on the page, it could be that the marker takes one of the
>>> attachments even if the user did not want a custom icon or an image
>>> different from what the user wanted to choose is selected as the marker
>>> icon.
>>>
>>> What I have in mind is that we define categories for marker icons
>>> dynamically.
>>> We could make a separate dedicated page "MarkerIcons" and attach
>>> multiple images to it. Then these images could appear in a list as one of
>>> the properties in the Point object where we can choose the icon from. WDYT?
>>>
>>> Thanks,
>>> Fawad
>>>
>>> On Tue, Jun 4, 2019, 11:31 AM Stéphane Laurière <[hidden email]
>>> wrote:
>>>
>>>> Fawad, Thanks for letting us know, I could install the new app version,
>>>> I confirm that all the changes you added to the progress file (very handy)
>>>> work for me, and the refactoring is ok. I noticed a minor issue that you're
>>>> certainly aware of already: it seems there's a small offset between the
>>>> custom marker position (with the Islamabad point) and the popup position.
>>>>
>>>> Talk to you soon,
>>>>
>>>> Stéphane
>>>>
>>>>
>>>> Fawad Ali:
>>>> > Hi all,
>>>> >
>>>> > Thanks for the detailed review, Stephane. I have made the changes you
>>>> suggested with some next steps also done.
>>>> >
>>>> > Furthermore, I will make changes to the application space once we
>>>> have confirmed response from Caty or other developers.
>>>> > I have started to work on the other next steps and will provide with
>>>> updates soon.
>>>> >
>>>> > The original github repo is also updated, so future updates will be
>>>> available at
>>>> https://github.com/xwiki-contrib/application-interactive-maps.
>>>> >
>>>> > Thanks,
>>>> > Fawad
>>>>
>>>>
>>>> --
>>>> Stéphane Laurière
>>>> XWiki – https://xwiki.com
>>>>
>>>>
>>>>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Ecaterina Moraru (Valica)
I've used the latest build from
https://github.com/9inpachi/interactive-maps-new
and I have the error both on 11.4-rc-1 and some 11.4-snapshot.

Thanks,
Caty

On Wed, Jun 5, 2019 at 8:30 PM Fawad Ali <[hidden email]> wrote:

> Hi,
>
> Caty, do you have the error with the latest git repo as well?
> Actually the leaflet-commons require leaflet but the functions are not
> actually called anywhere without the leaflet dependency used in require.
>
> There is no error on my or Stephane side.
> I have the 11.3-rc version of XWiki.
> You can try Ctrl+F5 for a complete new load of the resources.
>
> Best,
> Fawad
>
> On Wed, Jun 5, 2019, 10:22 PM Ecaterina Moraru (Valica) <[hidden email]
> wrote:
>
>> Hi,
>>
>> Some notes:
>> - We don't have guidelines regarding the singular / plural thing. I'm
>> glad that on the new sources we don't have the Maps/Map anymore. I'm fine
>> with Maps. In practice we have a mix of singular (like Diagram, Calendar,
>> Meeting) and plural (like Ideas, Forums). I prefer the plural version,
>> although in practice I think we have more with singular. There was a
>> tentative old draft for having such guidelines
>> https://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationGuidelines
>> but we didn't worked on it for some time.
>>
>> - Regarding the new Git repository. Since you've committed the initial
>> commits in issues, you should do a release with the initial version, and
>> than just release a new version for the interactive-maps-new . It's normal
>> in an application's development flow that changes happen, that's why
>> versioning schemes are all about.
>>
>> - I still have the error I've mentioned before :
>> Uncaught Error: Script error for "leaflet", needed by: leafletSearch
>> http://requirejs.org/docs/errors.html#scripterror
>>     at F (require.min.js?r=1:7)
>>     at HTMLScriptElement.onScriptError (require.min.js?r=1:30)
>>
>> leaflet.css:1 Failed to load resource: the server responded with a status
>> of 404 (Not Found)
>>
>> so I cannot actually test the build, since I don't see the maps. I have
>> this both on Chrome and Firefox. Do I need to do something?
>>
>> Thanks,
>> Caty
>>
>> On Tue, Jun 4, 2019 at 2:31 PM Fawad Ali <[hidden email]> wrote:
>>
>>> Also, I forgot to mention it before but we will need a better and more
>>> expressive way to show popups. We need something that can accomodate
>>> sufficient amount of text with a scroll if the information exceeds the page.
>>> I will prepare a mockup for this once I am done with some of the next
>>> steps.
>>>
>>> And I think we should use the colortheme colors for our map controls and
>>> consequently for the popups. I will update you on that as well.
>>>
>>> Best,
>>> Fawad
>>>
>>>
>>> On Tue, Jun 4, 2019 at 3:31 PM Fawad Ali <[hidden email]>
>>> wrote:
>>>
>>>> Hi Stephane, Caty and all,
>>>> Hope you are doing fine.
>>>>
>>>> I am glad you brought up the topic of custom marker icon. I am well
>>>> aware of the issue. Actually there are two problems with custom markers.
>>>> - The icon offset
>>>> - The document attachment
>>>>
>>>> For the icon offset, when I tried to fix it initially it seemed that I
>>>> can overcome the offset either by height or width which means that the
>>>> offset still exists from a single side so I had that postponed since I
>>>> thought solr query tasks take priority.
>>>>
>>>> For the attachment, for now I am getting the first attachment (0th
>>>> index) from the Point page which is not very reliable. For example if we
>>>> have images on the page, it could be that the marker takes one of the
>>>> attachments even if the user did not want a custom icon or an image
>>>> different from what the user wanted to choose is selected as the marker
>>>> icon.
>>>>
>>>> What I have in mind is that we define categories for marker icons
>>>> dynamically.
>>>> We could make a separate dedicated page "MarkerIcons" and attach
>>>> multiple images to it. Then these images could appear in a list as one of
>>>> the properties in the Point object where we can choose the icon from. WDYT?
>>>>
>>>> Thanks,
>>>> Fawad
>>>>
>>>> On Tue, Jun 4, 2019, 11:31 AM Stéphane Laurière <[hidden email]
>>>> wrote:
>>>>
>>>>> Fawad, Thanks for letting us know, I could install the new app
>>>>> version, I confirm that all the changes you added to the progress file
>>>>> (very handy) work for me, and the refactoring is ok. I noticed a minor
>>>>> issue that you're certainly aware of already: it seems there's a small
>>>>> offset between the custom marker position (with the Islamabad point) and
>>>>> the popup position.
>>>>>
>>>>> Talk to you soon,
>>>>>
>>>>> Stéphane
>>>>>
>>>>>
>>>>> Fawad Ali:
>>>>> > Hi all,
>>>>> >
>>>>> > Thanks for the detailed review, Stephane. I have made the changes
>>>>> you suggested with some next steps also done.
>>>>> >
>>>>> > Furthermore, I will make changes to the application space once we
>>>>> have confirmed response from Caty or other developers.
>>>>> > I have started to work on the other next steps and will provide with
>>>>> updates soon.
>>>>> >
>>>>> > The original github repo is also updated, so future updates will be
>>>>> available at
>>>>> https://github.com/xwiki-contrib/application-interactive-maps.
>>>>> >
>>>>> > Thanks,
>>>>> > Fawad
>>>>>
>>>>>
>>>>> --
>>>>> Stéphane Laurière
>>>>> XWiki – https://xwiki.com
>>>>>
>>>>>
>>>>>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Fawad Ali
We have shifted the repo to xwiki-contrib again. You may try that. I will
also check my own repo for any errors ASAP.

Best,
Fawad

On Wed, Jun 5, 2019, 10:35 PM Ecaterina Moraru (Valica) <[hidden email]
wrote:

> I've used the latest build from
> https://github.com/9inpachi/interactive-maps-new
> and I have the error both on 11.4-rc-1 and some 11.4-snapshot.
>
> Thanks,
> Caty
>
> On Wed, Jun 5, 2019 at 8:30 PM Fawad Ali <[hidden email]> wrote:
>
>> Hi,
>>
>> Caty, do you have the error with the latest git repo as well?
>> Actually the leaflet-commons require leaflet but the functions are not
>> actually called anywhere without the leaflet dependency used in require.
>>
>> There is no error on my or Stephane side.
>> I have the 11.3-rc version of XWiki.
>> You can try Ctrl+F5 for a complete new load of the resources.
>>
>> Best,
>> Fawad
>>
>> On Wed, Jun 5, 2019, 10:22 PM Ecaterina Moraru (Valica) <
>> [hidden email] wrote:
>>
>>> Hi,
>>>
>>> Some notes:
>>> - We don't have guidelines regarding the singular / plural thing. I'm
>>> glad that on the new sources we don't have the Maps/Map anymore. I'm fine
>>> with Maps. In practice we have a mix of singular (like Diagram, Calendar,
>>> Meeting) and plural (like Ideas, Forums). I prefer the plural version,
>>> although in practice I think we have more with singular. There was a
>>> tentative old draft for having such guidelines
>>> https://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationGuidelines
>>> but we didn't worked on it for some time.
>>>
>>> - Regarding the new Git repository. Since you've committed the initial
>>> commits in issues, you should do a release with the initial version, and
>>> than just release a new version for the interactive-maps-new . It's normal
>>> in an application's development flow that changes happen, that's why
>>> versioning schemes are all about.
>>>
>>> - I still have the error I've mentioned before :
>>> Uncaught Error: Script error for "leaflet", needed by: leafletSearch
>>> http://requirejs.org/docs/errors.html#scripterror
>>>     at F (require.min.js?r=1:7)
>>>     at HTMLScriptElement.onScriptError (require.min.js?r=1:30)
>>>
>>> leaflet.css:1 Failed to load resource: the server responded with a
>>> status of 404 (Not Found)
>>>
>>> so I cannot actually test the build, since I don't see the maps. I have
>>> this both on Chrome and Firefox. Do I need to do something?
>>>
>>> Thanks,
>>> Caty
>>>
>>> On Tue, Jun 4, 2019 at 2:31 PM Fawad Ali <[hidden email]>
>>> wrote:
>>>
>>>> Also, I forgot to mention it before but we will need a better and more
>>>> expressive way to show popups. We need something that can accomodate
>>>> sufficient amount of text with a scroll if the information exceeds the page.
>>>> I will prepare a mockup for this once I am done with some of the next
>>>> steps.
>>>>
>>>> And I think we should use the colortheme colors for our map controls
>>>> and consequently for the popups. I will update you on that as well.
>>>>
>>>> Best,
>>>> Fawad
>>>>
>>>>
>>>> On Tue, Jun 4, 2019 at 3:31 PM Fawad Ali <[hidden email]>
>>>> wrote:
>>>>
>>>>> Hi Stephane, Caty and all,
>>>>> Hope you are doing fine.
>>>>>
>>>>> I am glad you brought up the topic of custom marker icon. I am well
>>>>> aware of the issue. Actually there are two problems with custom markers.
>>>>> - The icon offset
>>>>> - The document attachment
>>>>>
>>>>> For the icon offset, when I tried to fix it initially it seemed that I
>>>>> can overcome the offset either by height or width which means that the
>>>>> offset still exists from a single side so I had that postponed since I
>>>>> thought solr query tasks take priority.
>>>>>
>>>>> For the attachment, for now I am getting the first attachment (0th
>>>>> index) from the Point page which is not very reliable. For example if we
>>>>> have images on the page, it could be that the marker takes one of the
>>>>> attachments even if the user did not want a custom icon or an image
>>>>> different from what the user wanted to choose is selected as the marker
>>>>> icon.
>>>>>
>>>>> What I have in mind is that we define categories for marker icons
>>>>> dynamically.
>>>>> We could make a separate dedicated page "MarkerIcons" and attach
>>>>> multiple images to it. Then these images could appear in a list as one of
>>>>> the properties in the Point object where we can choose the icon from. WDYT?
>>>>>
>>>>> Thanks,
>>>>> Fawad
>>>>>
>>>>> On Tue, Jun 4, 2019, 11:31 AM Stéphane Laurière <[hidden email]
>>>>> wrote:
>>>>>
>>>>>> Fawad, Thanks for letting us know, I could install the new app
>>>>>> version, I confirm that all the changes you added to the progress file
>>>>>> (very handy) work for me, and the refactoring is ok. I noticed a minor
>>>>>> issue that you're certainly aware of already: it seems there's a small
>>>>>> offset between the custom marker position (with the Islamabad point) and
>>>>>> the popup position.
>>>>>>
>>>>>> Talk to you soon,
>>>>>>
>>>>>> Stéphane
>>>>>>
>>>>>>
>>>>>> Fawad Ali:
>>>>>> > Hi all,
>>>>>> >
>>>>>> > Thanks for the detailed review, Stephane. I have made the changes
>>>>>> you suggested with some next steps also done.
>>>>>> >
>>>>>> > Furthermore, I will make changes to the application space once we
>>>>>> have confirmed response from Caty or other developers.
>>>>>> > I have started to work on the other next steps and will provide
>>>>>> with updates soon.
>>>>>> >
>>>>>> > The original github repo is also updated, so future updates will be
>>>>>> available at
>>>>>> https://github.com/xwiki-contrib/application-interactive-maps.
>>>>>> >
>>>>>> > Thanks,
>>>>>> > Fawad
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Stéphane Laurière
>>>>>> XWiki – https://xwiki.com
>>>>>>
>>>>>>
>>>>>>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Fawad Ali
I just built and imported the application from my own repo (
https://github.com/9inpachi/interactive-maps-new) and everything seems fine.

There was that error in the more earlier builds but it was fixed, may be
some of the source files (especially Leaflet.xml) are old?
Try building the source files anew with "mvn clean install". May be that
will help.

Thanks,
Fawad

On Wed, Jun 5, 2019, 10:37 PM Fawad Ali <[hidden email] wrote:

> We have shifted the repo to xwiki-contrib again. You may try that. I will
> also check my own repo for any errors ASAP.
>
> Best,
> Fawad
>
> On Wed, Jun 5, 2019, 10:35 PM Ecaterina Moraru (Valica) <[hidden email]
> wrote:
>
>> I've used the latest build from
>> https://github.com/9inpachi/interactive-maps-new
>> and I have the error both on 11.4-rc-1 and some 11.4-snapshot.
>>
>> Thanks,
>> Caty
>>
>> On Wed, Jun 5, 2019 at 8:30 PM Fawad Ali <[hidden email]> wrote:
>>
>>> Hi,
>>>
>>> Caty, do you have the error with the latest git repo as well?
>>> Actually the leaflet-commons require leaflet but the functions are not
>>> actually called anywhere without the leaflet dependency used in require.
>>>
>>> There is no error on my or Stephane side.
>>> I have the 11.3-rc version of XWiki.
>>> You can try Ctrl+F5 for a complete new load of the resources.
>>>
>>> Best,
>>> Fawad
>>>
>>> On Wed, Jun 5, 2019, 10:22 PM Ecaterina Moraru (Valica) <
>>> [hidden email] wrote:
>>>
>>>> Hi,
>>>>
>>>> Some notes:
>>>> - We don't have guidelines regarding the singular / plural thing. I'm
>>>> glad that on the new sources we don't have the Maps/Map anymore. I'm fine
>>>> with Maps. In practice we have a mix of singular (like Diagram, Calendar,
>>>> Meeting) and plural (like Ideas, Forums). I prefer the plural version,
>>>> although in practice I think we have more with singular. There was a
>>>> tentative old draft for having such guidelines
>>>> https://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationGuidelines
>>>> but we didn't worked on it for some time.
>>>>
>>>> - Regarding the new Git repository. Since you've committed the initial
>>>> commits in issues, you should do a release with the initial version, and
>>>> than just release a new version for the interactive-maps-new . It's normal
>>>> in an application's development flow that changes happen, that's why
>>>> versioning schemes are all about.
>>>>
>>>> - I still have the error I've mentioned before :
>>>> Uncaught Error: Script error for "leaflet", needed by: leafletSearch
>>>> http://requirejs.org/docs/errors.html#scripterror
>>>>     at F (require.min.js?r=1:7)
>>>>     at HTMLScriptElement.onScriptError (require.min.js?r=1:30)
>>>>
>>>> leaflet.css:1 Failed to load resource: the server responded with a
>>>> status of 404 (Not Found)
>>>>
>>>> so I cannot actually test the build, since I don't see the maps. I have
>>>> this both on Chrome and Firefox. Do I need to do something?
>>>>
>>>> Thanks,
>>>> Caty
>>>>
>>>> On Tue, Jun 4, 2019 at 2:31 PM Fawad Ali <[hidden email]>
>>>> wrote:
>>>>
>>>>> Also, I forgot to mention it before but we will need a better and more
>>>>> expressive way to show popups. We need something that can accomodate
>>>>> sufficient amount of text with a scroll if the information exceeds the page.
>>>>> I will prepare a mockup for this once I am done with some of the next
>>>>> steps.
>>>>>
>>>>> And I think we should use the colortheme colors for our map controls
>>>>> and consequently for the popups. I will update you on that as well.
>>>>>
>>>>> Best,
>>>>> Fawad
>>>>>
>>>>>
>>>>> On Tue, Jun 4, 2019 at 3:31 PM Fawad Ali <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> Hi Stephane, Caty and all,
>>>>>> Hope you are doing fine.
>>>>>>
>>>>>> I am glad you brought up the topic of custom marker icon. I am well
>>>>>> aware of the issue. Actually there are two problems with custom markers.
>>>>>> - The icon offset
>>>>>> - The document attachment
>>>>>>
>>>>>> For the icon offset, when I tried to fix it initially it seemed that
>>>>>> I can overcome the offset either by height or width which means that the
>>>>>> offset still exists from a single side so I had that postponed since I
>>>>>> thought solr query tasks take priority.
>>>>>>
>>>>>> For the attachment, for now I am getting the first attachment (0th
>>>>>> index) from the Point page which is not very reliable. For example if we
>>>>>> have images on the page, it could be that the marker takes one of the
>>>>>> attachments even if the user did not want a custom icon or an image
>>>>>> different from what the user wanted to choose is selected as the marker
>>>>>> icon.
>>>>>>
>>>>>> What I have in mind is that we define categories for marker icons
>>>>>> dynamically.
>>>>>> We could make a separate dedicated page "MarkerIcons" and attach
>>>>>> multiple images to it. Then these images could appear in a list as one of
>>>>>> the properties in the Point object where we can choose the icon from. WDYT?
>>>>>>
>>>>>> Thanks,
>>>>>> Fawad
>>>>>>
>>>>>> On Tue, Jun 4, 2019, 11:31 AM Stéphane Laurière <[hidden email]
>>>>>> wrote:
>>>>>>
>>>>>>> Fawad, Thanks for letting us know, I could install the new app
>>>>>>> version, I confirm that all the changes you added to the progress file
>>>>>>> (very handy) work for me, and the refactoring is ok. I noticed a minor
>>>>>>> issue that you're certainly aware of already: it seems there's a small
>>>>>>> offset between the custom marker position (with the Islamabad point) and
>>>>>>> the popup position.
>>>>>>>
>>>>>>> Talk to you soon,
>>>>>>>
>>>>>>> Stéphane
>>>>>>>
>>>>>>>
>>>>>>> Fawad Ali:
>>>>>>> > Hi all,
>>>>>>> >
>>>>>>> > Thanks for the detailed review, Stephane. I have made the changes
>>>>>>> you suggested with some next steps also done.
>>>>>>> >
>>>>>>> > Furthermore, I will make changes to the application space once we
>>>>>>> have confirmed response from Caty or other developers.
>>>>>>> > I have started to work on the other next steps and will provide
>>>>>>> with updates soon.
>>>>>>> >
>>>>>>> > The original github repo is also updated, so future updates will
>>>>>>> be available at
>>>>>>> https://github.com/xwiki-contrib/application-interactive-maps.
>>>>>>> >
>>>>>>> > Thanks,
>>>>>>> > Fawad
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Stéphane Laurière
>>>>>>> XWiki – https://xwiki.com
>>>>>>>
>>>>>>>
>>>>>>>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Ecaterina Moraru (Valica)
Hi Fawad,

I still have the issue: no maps loaded, leaflet.css error in console.
Tested with the most recent snapshot of 11.5 and with the build from
https://github.com/xwiki-contrib/application-interactive-maps
I have the same problem with Firefox, Chrome, Safari and Opera. I'm on Mac.
https://up1.xwikisas.com/#mXONZtF2qcMeftvnyJOSjw
The script from “
http://localhost:8084/xwiki/webjars/wiki%3Axwiki/leaflet/leaflet.js?r=1”
was loaded even though its MIME type (“text/html”) is not a valid
JavaScript MIME type.

Also Maps.MapTesting.Points.Islamabad.WebHome page seems to have error when
importing (with the "Replace the page history with the history from the
package" option) https://up1.xwikisas.com/#ag8AIsPHgcFYqVod2RMJQQ

Thanks,
Caty


On Wed, Jun 5, 2019 at 8:50 PM Fawad Ali <[hidden email]> wrote:

> I just built and imported the application from my own repo (
> https://github.com/9inpachi/interactive-maps-new) and everything seems
> fine.
>
> There was that error in the more earlier builds but it was fixed, may be
> some of the source files (especially Leaflet.xml) are old?
> Try building the source files anew with "mvn clean install". May be that
> will help.
>
> Thanks,
> Fawad
>
> On Wed, Jun 5, 2019, 10:37 PM Fawad Ali <[hidden email] wrote:
>
>> We have shifted the repo to xwiki-contrib again. You may try that. I will
>> also check my own repo for any errors ASAP.
>>
>> Best,
>> Fawad
>>
>> On Wed, Jun 5, 2019, 10:35 PM Ecaterina Moraru (Valica) <
>> [hidden email] wrote:
>>
>>> I've used the latest build from
>>> https://github.com/9inpachi/interactive-maps-new
>>> and I have the error both on 11.4-rc-1 and some 11.4-snapshot.
>>>
>>> Thanks,
>>> Caty
>>>
>>> On Wed, Jun 5, 2019 at 8:30 PM Fawad Ali <[hidden email]>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Caty, do you have the error with the latest git repo as well?
>>>> Actually the leaflet-commons require leaflet but the functions are not
>>>> actually called anywhere without the leaflet dependency used in require.
>>>>
>>>> There is no error on my or Stephane side.
>>>> I have the 11.3-rc version of XWiki.
>>>> You can try Ctrl+F5 for a complete new load of the resources.
>>>>
>>>> Best,
>>>> Fawad
>>>>
>>>> On Wed, Jun 5, 2019, 10:22 PM Ecaterina Moraru (Valica) <
>>>> [hidden email] wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Some notes:
>>>>> - We don't have guidelines regarding the singular / plural thing. I'm
>>>>> glad that on the new sources we don't have the Maps/Map anymore. I'm fine
>>>>> with Maps. In practice we have a mix of singular (like Diagram, Calendar,
>>>>> Meeting) and plural (like Ideas, Forums). I prefer the plural version,
>>>>> although in practice I think we have more with singular. There was a
>>>>> tentative old draft for having such guidelines
>>>>> https://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationGuidelines
>>>>> but we didn't worked on it for some time.
>>>>>
>>>>> - Regarding the new Git repository. Since you've committed the initial
>>>>> commits in issues, you should do a release with the initial version, and
>>>>> than just release a new version for the interactive-maps-new . It's normal
>>>>> in an application's development flow that changes happen, that's why
>>>>> versioning schemes are all about.
>>>>>
>>>>> - I still have the error I've mentioned before :
>>>>> Uncaught Error: Script error for "leaflet", needed by: leafletSearch
>>>>> http://requirejs.org/docs/errors.html#scripterror
>>>>>     at F (require.min.js?r=1:7)
>>>>>     at HTMLScriptElement.onScriptError (require.min.js?r=1:30)
>>>>>
>>>>> leaflet.css:1 Failed to load resource: the server responded with a
>>>>> status of 404 (Not Found)
>>>>>
>>>>> so I cannot actually test the build, since I don't see the maps. I
>>>>> have this both on Chrome and Firefox. Do I need to do something?
>>>>>
>>>>> Thanks,
>>>>> Caty
>>>>>
>>>>> On Tue, Jun 4, 2019 at 2:31 PM Fawad Ali <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> Also, I forgot to mention it before but we will need a better and
>>>>>> more expressive way to show popups. We need something that can accomodate
>>>>>> sufficient amount of text with a scroll if the information exceeds the page.
>>>>>> I will prepare a mockup for this once I am done with some of the next
>>>>>> steps.
>>>>>>
>>>>>> And I think we should use the colortheme colors for our map controls
>>>>>> and consequently for the popups. I will update you on that as well.
>>>>>>
>>>>>> Best,
>>>>>> Fawad
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 4, 2019 at 3:31 PM Fawad Ali <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Stephane, Caty and all,
>>>>>>> Hope you are doing fine.
>>>>>>>
>>>>>>> I am glad you brought up the topic of custom marker icon. I am well
>>>>>>> aware of the issue. Actually there are two problems with custom markers.
>>>>>>> - The icon offset
>>>>>>> - The document attachment
>>>>>>>
>>>>>>> For the icon offset, when I tried to fix it initially it seemed that
>>>>>>> I can overcome the offset either by height or width which means that the
>>>>>>> offset still exists from a single side so I had that postponed since I
>>>>>>> thought solr query tasks take priority.
>>>>>>>
>>>>>>> For the attachment, for now I am getting the first attachment (0th
>>>>>>> index) from the Point page which is not very reliable. For example if we
>>>>>>> have images on the page, it could be that the marker takes one of the
>>>>>>> attachments even if the user did not want a custom icon or an image
>>>>>>> different from what the user wanted to choose is selected as the marker
>>>>>>> icon.
>>>>>>>
>>>>>>> What I have in mind is that we define categories for marker icons
>>>>>>> dynamically.
>>>>>>> We could make a separate dedicated page "MarkerIcons" and attach
>>>>>>> multiple images to it. Then these images could appear in a list as one of
>>>>>>> the properties in the Point object where we can choose the icon from. WDYT?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Fawad
>>>>>>>
>>>>>>> On Tue, Jun 4, 2019, 11:31 AM Stéphane Laurière <[hidden email]
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Fawad, Thanks for letting us know, I could install the new app
>>>>>>>> version, I confirm that all the changes you added to the progress file
>>>>>>>> (very handy) work for me, and the refactoring is ok. I noticed a minor
>>>>>>>> issue that you're certainly aware of already: it seems there's a small
>>>>>>>> offset between the custom marker position (with the Islamabad point) and
>>>>>>>> the popup position.
>>>>>>>>
>>>>>>>> Talk to you soon,
>>>>>>>>
>>>>>>>> Stéphane
>>>>>>>>
>>>>>>>>
>>>>>>>> Fawad Ali:
>>>>>>>> > Hi all,
>>>>>>>> >
>>>>>>>> > Thanks for the detailed review, Stephane. I have made the changes
>>>>>>>> you suggested with some next steps also done.
>>>>>>>> >
>>>>>>>> > Furthermore, I will make changes to the application space once we
>>>>>>>> have confirmed response from Caty or other developers.
>>>>>>>> > I have started to work on the other next steps and will provide
>>>>>>>> with updates soon.
>>>>>>>> >
>>>>>>>> > The original github repo is also updated, so future updates will
>>>>>>>> be available at
>>>>>>>> https://github.com/xwiki-contrib/application-interactive-maps.
>>>>>>>> >
>>>>>>>> > Thanks,
>>>>>>>> > Fawad
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Stéphane Laurière
>>>>>>>> XWiki – https://xwiki.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
12345 ... 7