subject:"\[xwiki\-devs\] Map Application \- GSoC 19"

Stephane,

I think the users would require an editor.
Having to create each shape separately would be cumbersome for them.
Especially with the case of indoor structures where potentially 10-20
shapes would be created for each level on average.

If an advance user does want to link marker icons with facet values he can
use the same kind of images for points and attach a custom class object to
categorize them. I don't think it should be prioritized above the editor.

Best,
Fawad

On Wed, Aug 21, 2019, 5:51 PM Stéphane Laurière  wrote:

>
> > Stéphane,
> > Thanks for the review.
> >
> > I understand that shapes should be separate objects.
> > Then, we need a way for users to easily create the large number of
> shapes required for each level of indoor structures.
> > Should I create a separate shape editor that will easily generate a
> number of shapes inside a specific space? How does that sound?
>
> It would be useful indeed, it seems we're reaching the point where we
> consider doing a real map editor in addition to a map viewer. I'm just
> wondering how it goes in terms of priorities and preferences, since having
> a working structure for dealing with semi-advanced map styles (I have in
> mind in particular the capacity to associate marker icons with facet
> values) and also a full-fledged demo showcasing all the major features
> would be interesting as well. It depends on your inclination really, I feel
> like you prefer progressing on the editor? Do you still plan to write a
> small report by the end of the GSoC as well?
>
> Stéphane
>
>

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





Stéphane,
Thanks for the review.

I understand that shapes should be separate objects.
Then, we need a way for users to easily create the large number of shapes 
required for each level of indoor structures.
Should I create a separate shape editor that will easily generate a number of 
shapes inside a specific space? How does that sound?


It would be useful indeed, it seems we're reaching the point where we consider 
doing a real map editor in addition to a map viewer. I'm just wondering how it 
goes in terms of priorities and preferences, since having a working structure 
for dealing with semi-advanced map styles (I have in mind in particular the 
capacity to associate marker icons with facet values) and also a full-fledged 
demo showcasing all the major features would be interesting as well. It depends 
on your inclination really, I feel like you prefer progressing on the editor? 
Do you still plan to write a small report by the end of the GSoC as well?

Stéphane

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

Stéphane,
Thanks for the review.

I understand that shapes should be separate objects.
Then, we need a way for users to easily create the large number of shapes
required for each level of indoor structures.
Should I create a separate shape editor that will easily generate a number
of shapes inside a specific space? How does that sound?

Best,
Fawad

On Wed, Aug 21, 2019 at 4:16 PM Stéphane Laurière 
wrote:

> > Fairly simple ones like visually defining popup content and style for
> each shape separately similar to the uMap editor.
> > Something like: https://up1.xwikisas.com/#eQ9Mck57dv0U0A7kpAvumQ
> > If there are any suggestions you think should be available as options,
> let me know.
>
> I see. These options are not specific to indoor maps, right? Regarding the
> title and the content, as mentioned in my previous message, I'd go for
> using the shape's page title and content themselves, if possible.
>
> Stéphane
>
>
>
>
>

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


Fairly simple ones like visually defining popup content and style for each 
shape separately similar to the uMap editor.
Something like: https://up1.xwikisas.com/#eQ9Mck57dv0U0A7kpAvumQ
If there are any suggestions you think should be available as options, let me 
know.


I see. These options are not specific to indoor maps, right? Regarding the 
title and the content, as mentioned in my previous message, I'd go for using 
the shape's page title and content themselves, if possible.

Stéphane

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







A better structure could also look like:
-
-1:Maps.Shapes.Shape1, Maps.Shapes.Shape2
0:Maps.Shapes.Shape3
1:Maps.Shapes.Shape4, Maps.Shapes.Shape5
-


Indeed, we could go this way and see how it goes. At some point, users will 
probably need a visual assistant to maintain this structure, we can address 
that later on.

Cheers

Stéphane

[xwiki-devs] Map Application - GSoC 19


Fawad, all,


Stéphane,

With the latest iteration, the ShapeClass is able to handle multiple shapes in 
a single Shape object.
Do you think that's fine or should there be separate objects for each shape?


I'd follow the same reasoning as for points and have one shape per page, 
because imho users will typically want to associate content to each shape, and 
the most suitable approach for handling content in XWiki (title, content, 
translations) is a page (image you create a map of a touristic region with 
various shapes with content to be available in various languages, that would be 
cumbersome to manage the content translations in objects rather than in pages). 
There could be special situations with several shapes attached to a single page 
though, that would be an advanced feature, for addressing the case of places 
which span across several locations, e.g. a large hospital covering several 
distinct areas in the same neighbourhood. What do you think?

Cheers

Stéphane



Best,
Fawadx

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

Stéphane,

With the latest iteration, the ShapeClass is able to handle multiple shapes
in a single Shape object.
Do you think that's fine or should there be separate objects for each shape?

Best,
Fawadx


On Wed, Aug 21, 2019 at 2:33 PM Fawad Ali  wrote:

> A better structure could also look like:
> -
> -1:Maps.Shapes.Shape1, Maps.Shapes.Shape2
> 0:Maps.Shapes.Shape3
> 1:Maps.Shapes.Shape4,  Maps.Shapes.Shape5
> -
>
> Best,
> Fawad
>
>
> On Wed, Aug 21, 2019 at 2:31 PM Fawad Ali  wrote:
>
>> Hi Stephane, all,
>> Hope you are having a great day.
>>
>>
>>> Right, that will be useful to associate shapes (and points as well?) to
>>> each level.
>>>
>>
>> Yes, points are also available within the shape editor.
>>
>> That could work indeed, but won't it be a bit cumbersome if a user has
>>> many shapes at a given level? We could also introduce a Level class and let
>>> the user associate a shape with a specific level, what do you think?
>>
>>
>> Sounds great but would that not become a two way process for the user?
>> The user will have to first create a level and then add all the levels
>> into an indoor structure. While he can do the same inside a single class.
>> Another option we can opt is to have a custom structure like custom
>> classes. (Which I think is more flexible to our needs)
>> Something like:
>> -
>> -1:Maps.Shapes.Shape1
>> -1:Maps.Shapes.Shape2
>> 0:Maps.Shapes.Shape3
>> 1:Maps.Shapes.Shape4
>> 1:Maps.Shapes.Shape5
>> -
>>
>>
>>>  Great. What specific options do you have in mind for indoor?
>>
>>
>> Fairly simple ones like visually defining popup content and style for
>> each shape separately similar to the uMap editor.
>> Something like: https://up1.xwikisas.com/#eQ9Mck57dv0U0A7kpAvumQ
>> If there are any suggestions you think should be available as options,
>> let me know.
>>
>> Peace,
>> Fawad
>>
>>
>> On Wed, Aug 21, 2019 at 1:49 PM Stéphane Laurière 
>> wrote:
>>
>>> Hi Fawad, Hi all,
>>>
>>> > Hi all,
>>> >
>>> > After much analyzing I have found a good workflow for creating indoor
>>> maps.
>>> > What I have in mind is that we treat indoor structures as map items
>>> rather than a completely separate map.
>>>
>>> This sounds like a good approach indeed imho.
>>>
>>> > The levels can be specified along with the shapes to be used for each
>>> level. Each shape will be created separately using the ShapeSheet.
>>>
>>> Right, that will be useful to associate shapes (and points as well?) to
>>> each level.
>>>
>>> > We can have a static list for indoor levels and another one for
>>> shapes. The shapes will be selected in order of the levels defined.
>>> > For example,
>>> > *Shapes List:* Shape1|Shape2}Shape3
>>> > *Levels List:* -1|0|1
>>> > In this case, level 0 will be mapped to Shape2.
>>>
>>> That could work indeed, but won't it be a bit cumbersome if a user has
>>> many shapes at a given level? We could also introduce a Level class and let
>>> the user associate a shape with a specific level, what do you think?
>>>
>>> > I am working on separately defining options for each shape so they can
>>> be better used with indoor structures.
>>>
>>> Great. What specific options do you have in mind for indoor?
>>>
>>> Cheers
>>>
>>> Stéphane
>>>
>>>
>>>
>>> > What do you think?
>>> >
>>> > Best,
>>> > Fawad
>>>
>>>

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

A better structure could also look like:
-
-1:Maps.Shapes.Shape1, Maps.Shapes.Shape2
0:Maps.Shapes.Shape3
1:Maps.Shapes.Shape4,  Maps.Shapes.Shape5
-

Best,
Fawad


On Wed, Aug 21, 2019 at 2:31 PM Fawad Ali  wrote:

> Hi Stephane, all,
> Hope you are having a great day.
>
>
>> Right, that will be useful to associate shapes (and points as well?) to
>> each level.
>>
>
> Yes, points are also available within the shape editor.
>
> That could work indeed, but won't it be a bit cumbersome if a user has
>> many shapes at a given level? We could also introduce a Level class and let
>> the user associate a shape with a specific level, what do you think?
>
>
> Sounds great but would that not become a two way process for the user?
> The user will have to first create a level and then add all the levels
> into an indoor structure. While he can do the same inside a single class.
> Another option we can opt is to have a custom structure like custom
> classes. (Which I think is more flexible to our needs)
> Something like:
> -
> -1:Maps.Shapes.Shape1
> -1:Maps.Shapes.Shape2
> 0:Maps.Shapes.Shape3
> 1:Maps.Shapes.Shape4
> 1:Maps.Shapes.Shape5
> -
>
>
>>  Great. What specific options do you have in mind for indoor?
>
>
> Fairly simple ones like visually defining popup content and style for each
> shape separately similar to the uMap editor.
> Something like: https://up1.xwikisas.com/#eQ9Mck57dv0U0A7kpAvumQ
> If there are any suggestions you think should be available as options, let
> me know.
>
> Peace,
> Fawad
>
>
> On Wed, Aug 21, 2019 at 1:49 PM Stéphane Laurière 
> wrote:
>
>> Hi Fawad, Hi all,
>>
>> > Hi all,
>> >
>> > After much analyzing I have found a good workflow for creating indoor
>> maps.
>> > What I have in mind is that we treat indoor structures as map items
>> rather than a completely separate map.
>>
>> This sounds like a good approach indeed imho.
>>
>> > The levels can be specified along with the shapes to be used for each
>> level. Each shape will be created separately using the ShapeSheet.
>>
>> Right, that will be useful to associate shapes (and points as well?) to
>> each level.
>>
>> > We can have a static list for indoor levels and another one for shapes.
>> The shapes will be selected in order of the levels defined.
>> > For example,
>> > *Shapes List:* Shape1|Shape2}Shape3
>> > *Levels List:* -1|0|1
>> > In this case, level 0 will be mapped to Shape2.
>>
>> That could work indeed, but won't it be a bit cumbersome if a user has
>> many shapes at a given level? We could also introduce a Level class and let
>> the user associate a shape with a specific level, what do you think?
>>
>> > I am working on separately defining options for each shape so they can
>> be better used with indoor structures.
>>
>> Great. What specific options do you have in mind for indoor?
>>
>> Cheers
>>
>> Stéphane
>>
>>
>>
>> > What do you think?
>> >
>> > Best,
>> > Fawad
>>
>>

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

Hi Stephane, all,
Hope you are having a great day.


> Right, that will be useful to associate shapes (and points as well?) to
> each level.
>

Yes, points are also available within the shape editor.

That could work indeed, but won't it be a bit cumbersome if a user has many
> shapes at a given level? We could also introduce a Level class and let the
> user associate a shape with a specific level, what do you think?


Sounds great but would that not become a two way process for the user?
The user will have to first create a level and then add all the levels into
an indoor structure. While he can do the same inside a single class.
Another option we can opt is to have a custom structure like custom
classes. (Which I think is more flexible to our needs)
Something like:
-
-1:Maps.Shapes.Shape1
-1:Maps.Shapes.Shape2
0:Maps.Shapes.Shape3
1:Maps.Shapes.Shape4
1:Maps.Shapes.Shape5
-


>  Great. What specific options do you have in mind for indoor?


Fairly simple ones like visually defining popup content and style for each
shape separately similar to the uMap editor.
Something like: https://up1.xwikisas.com/#eQ9Mck57dv0U0A7kpAvumQ
If there are any suggestions you think should be available as options, let
me know.

Peace,
Fawad


On Wed, Aug 21, 2019 at 1:49 PM Stéphane Laurière 
wrote:

> Hi Fawad, Hi all,
>
> > Hi all,
> >
> > After much analyzing I have found a good workflow for creating indoor
> maps.
> > What I have in mind is that we treat indoor structures as map items
> rather than a completely separate map.
>
> This sounds like a good approach indeed imho.
>
> > The levels can be specified along with the shapes to be used for each
> level. Each shape will be created separately using the ShapeSheet.
>
> Right, that will be useful to associate shapes (and points as well?) to
> each level.
>
> > We can have a static list for indoor levels and another one for shapes.
> The shapes will be selected in order of the levels defined.
> > For example,
> > *Shapes List:* Shape1|Shape2}Shape3
> > *Levels List:* -1|0|1
> > In this case, level 0 will be mapped to Shape2.
>
> That could work indeed, but won't it be a bit cumbersome if a user has
> many shapes at a given level? We could also introduce a Level class and let
> the user associate a shape with a specific level, what do you think?
>
> > I am working on separately defining options for each shape so they can
> be better used with indoor structures.
>
> Great. What specific options do you have in mind for indoor?
>
> Cheers
>
> Stéphane
>
>
>
> > What do you think?
> >
> > Best,
> > Fawad
>
>

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


Hi Fawad, Hi all,


Hi all,

After much analyzing I have found a good workflow for creating indoor maps.
What I have in mind is that we treat indoor structures as map items rather than a completely separate map. 


This sounds like a good approach indeed imho.


The levels can be specified along with the shapes to be used for each level. 
Each shape will be created separately using the ShapeSheet.


Right, that will be useful to associate shapes (and points as well?) to each 
level.


We can have a static list for indoor levels and another one for shapes. The 
shapes will be selected in order of the levels defined.
For example,
*Shapes List:* Shape1|Shape2}Shape3
*Levels List:* -1|0|1
In this case, level 0 will be mapped to Shape2.


That could work indeed, but won't it be a bit cumbersome if a user has many 
shapes at a given level? We could also introduce a Level class and let the user 
associate a shape with a specific level, what do you think?


I am working on separately defining options for each shape so they can be 
better used with indoor structures.


Great. What specific options do you have in mind for indoor?

Cheers

Stéphane


 

What do you think?

Best,
Fawad

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

2019-08-20 Thread Fawad Ali

Hi all,

After much analyzing I have found a good workflow for creating indoor maps.
What I have in mind is that we treat indoor structures as map items rather
than a completely separate map. The levels can be specified along with the
shapes to be used for each level. Each shape will be created separately
using the ShapeSheet.
We can have a static list for indoor levels and another one for shapes. The
shapes will be selected in order of the levels defined.
For example,
*Shapes List:* Shape1|Shape2}Shape3
*Levels List:* -1|0|1
In this case, level 0 will be mapped to Shape2.

I am working on separately defining options for each shape so they can be
better used with indoor structures.

What do you think?

Best,
Fawad


On Tue, Aug 20, 2019 at 3:24 PM Fawad Ali  wrote:

> For now, I will move towards the implementation of leaflet-indoor as the
> base and if there is time, I will also implement the image option since it
> will be a lot useful.
>
> Best,
> Fawad
>
>
> On Tue, Aug 20, 2019 at 3:22 PM Fawad Ali  wrote:
>
>> Hi all,
>>
>> One concern in using the leaflet-indoor is that the indoor structures
>> might not physically exist.
>> For example, if an engineer prepares a model for a house and wants to
>> represent the structure in an independent environment then he will prefer
>> the image as map tiles. (
>> https://leafletjs.com/examples/crs-simple/crs-simple.html )
>>
>> Best,
>> Fawad
>>
>>
>> On Tue, Aug 20, 2019 at 1:46 PM Stéphane Laurière 
>> wrote:
>>
>>> Hi Fawad, Hi all,
>>>
>>> > Hi everyone,
>>> > Hope all of you are all right.
>>> >
>>> > I am working on the implementation of Indoor Maps. For that, there are
>>> several options for adaptation. So I need your suggestions.
>>> > The first question is how would the users be using the indoor maps?
>>> > - Would they be using images for each level?
>>> > - Would they prefer to have a normal map and add shape-like objects to
>>> it?
>>> > - Or would they like a mixture of both i.e. a normal map with images
>>> as levels?
>>> >
>>> > For a normal map with multilevel structures - we can use
>>> https://github.com/cbaines/leaflet-indoor
>>> > For using only images - we can make use of
>>> https://leafletjs.com/examples/crs-simple/crs-simple.html
>>> >
>>> > What do you think would be best considering the map's user base?
>>>
>>> Initially I thought about images since many fair organizers provide PDF
>>> plans that could be converted into images, but on second thoughts, starting
>>> primarily with shapes could be even better in terms of user experience
>>> imho. Nothing prevents from adding images in addition in the future, if
>>> some users prefer that approach, or a mix as you suggest.
>>>
>>> This kind of experience is quite inspirational in particular (it's close
>>> to the leaflet-indoor example that you pointed out):
>>>
>>>
>>> https://use.mazemap.com/#v=1&zlevel=1&left=6.8518492&right=6.8576924&top=52.2403051&bottom=52.2384279&campusid=171
>>>
>>> That's a question you may consider asking on the forum as well to gather
>>> more inputs?
>>>
>>> Cheers
>>>
>>> Stéphane
>>>
>>>
>>>
>>> > Best,
>>> > Fawad
>>> >
>>> >
>>>
>>>

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

2019-08-20 Thread Fawad Ali

For now, I will move towards the implementation of leaflet-indoor as the
base and if there is time, I will also implement the image option since it
will be a lot useful.

Best,
Fawad


On Tue, Aug 20, 2019 at 3:22 PM Fawad Ali  wrote:

> Hi all,
>
> One concern in using the leaflet-indoor is that the indoor structures
> might not physically exist.
> For example, if an engineer prepares a model for a house and wants to
> represent the structure in an independent environment then he will prefer
> the image as map tiles. (
> https://leafletjs.com/examples/crs-simple/crs-simple.html )
>
> Best,
> Fawad
>
>
> On Tue, Aug 20, 2019 at 1:46 PM Stéphane Laurière 
> wrote:
>
>> Hi Fawad, Hi all,
>>
>> > Hi everyone,
>> > Hope all of you are all right.
>> >
>> > I am working on the implementation of Indoor Maps. For that, there are
>> several options for adaptation. So I need your suggestions.
>> > The first question is how would the users be using the indoor maps?
>> > - Would they be using images for each level?
>> > - Would they prefer to have a normal map and add shape-like objects to
>> it?
>> > - Or would they like a mixture of both i.e. a normal map with images as
>> levels?
>> >
>> > For a normal map with multilevel structures - we can use
>> https://github.com/cbaines/leaflet-indoor
>> > For using only images - we can make use of
>> https://leafletjs.com/examples/crs-simple/crs-simple.html
>> >
>> > What do you think would be best considering the map's user base?
>>
>> Initially I thought about images since many fair organizers provide PDF
>> plans that could be converted into images, but on second thoughts, starting
>> primarily with shapes could be even better in terms of user experience
>> imho. Nothing prevents from adding images in addition in the future, if
>> some users prefer that approach, or a mix as you suggest.
>>
>> This kind of experience is quite inspirational in particular (it's close
>> to the leaflet-indoor example that you pointed out):
>>
>>
>> https://use.mazemap.com/#v=1&zlevel=1&left=6.8518492&right=6.8576924&top=52.2403051&bottom=52.2384279&campusid=171
>>
>> That's a question you may consider asking on the forum as well to gather
>> more inputs?
>>
>> Cheers
>>
>> Stéphane
>>
>>
>>
>> > Best,
>> > Fawad
>> >
>> >
>>
>>

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

2019-08-20 Thread Fawad Ali

Hi all,

One concern in using the leaflet-indoor is that the indoor structures might
not physically exist.
For example, if an engineer prepares a model for a house and wants to
represent the structure in an independent environment then he will prefer
the image as map tiles. (
https://leafletjs.com/examples/crs-simple/crs-simple.html )

Best,
Fawad


On Tue, Aug 20, 2019 at 1:46 PM Stéphane Laurière 
wrote:

> Hi Fawad, Hi all,
>
> > Hi everyone,
> > Hope all of you are all right.
> >
> > I am working on the implementation of Indoor Maps. For that, there are
> several options for adaptation. So I need your suggestions.
> > The first question is how would the users be using the indoor maps?
> > - Would they be using images for each level?
> > - Would they prefer to have a normal map and add shape-like objects to
> it?
> > - Or would they like a mixture of both i.e. a normal map with images as
> levels?
> >
> > For a normal map with multilevel structures - we can use
> https://github.com/cbaines/leaflet-indoor
> > For using only images - we can make use of
> https://leafletjs.com/examples/crs-simple/crs-simple.html
> >
> > What do you think would be best considering the map's user base?
>
> Initially I thought about images since many fair organizers provide PDF
> plans that could be converted into images, but on second thoughts, starting
> primarily with shapes could be even better in terms of user experience
> imho. Nothing prevents from adding images in addition in the future, if
> some users prefer that approach, or a mix as you suggest.
>
> This kind of experience is quite inspirational in particular (it's close
> to the leaflet-indoor example that you pointed out):
>
>
> https://use.mazemap.com/#v=1&zlevel=1&left=6.8518492&right=6.8576924&top=52.2403051&bottom=52.2384279&campusid=171
>
> That's a question you may consider asking on the forum as well to gather
> more inputs?
>
> Cheers
>
> Stéphane
>
>
>
> > Best,
> > Fawad
> >
> >
>
>

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

2019-08-20 Thread Stéphane Laurière


Hi Fawad, Hi all,


Hi everyone,
Hope all of you are all right.

I am working on the implementation of Indoor Maps. For that, there are several 
options for adaptation. So I need your suggestions.
The first question is how would the users be using the indoor maps?
- Would they be using images for each level?
- Would they prefer to have a normal map and add shape-like objects to it?
- Or would they like a mixture of both i.e. a normal map with images as levels?

For a normal map with multilevel structures - we can use 
https://github.com/cbaines/leaflet-indoor
For using only images - we can make use of 
https://leafletjs.com/examples/crs-simple/crs-simple.html

What do you think would be best considering the map's user base?


Initially I thought about images since many fair organizers provide PDF plans 
that could be converted into images, but on second thoughts, starting primarily 
with shapes could be even better in terms of user experience imho. Nothing 
prevents from adding images in addition in the future, if some users prefer 
that approach, or a mix as you suggest.

This kind of experience is quite inspirational in particular (it's close to the 
leaflet-indoor example that you pointed out):

  
https://use.mazemap.com/#v=1&zlevel=1&left=6.8518492&right=6.8576924&top=52.2403051&bottom=52.2384279&campusid=171

That's a question you may consider asking on the forum as well to gather more 
inputs?

Cheers

Stéphane


 

Best,
Fawad

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

2019-08-19 Thread Fawad Ali

Hi everyone,
Hope all of you are all right.

I am working on the implementation of Indoor Maps. For that, there are
several options for adaptation. So I need your suggestions.
The first question is how would the users be using the indoor maps?
- Would they be using images for each level?
- Would they prefer to have a normal map and add shape-like objects to it?
- Or would they like a mixture of both i.e. a normal map with images as
levels?

For a normal map with multilevel structures - we can use
https://github.com/cbaines/leaflet-indoor
For using only images - we can make use of
https://leafletjs.com/examples/crs-simple/crs-simple.html

What do you think would be best considering the map's user base?

Best,
Fawad


On Fri, Aug 2, 2019 at 5:53 PM Fawad Ali  wrote:

> Hi all,
>
> I wanted to ask if it was possible to have a custom class sheet and the
> editing options of a normal page available at the same time?
> As it stands, for the PointSheet, we will have to skip the WYSIWYG editor
> for editing the page. However, one thing could be that instead of taking
> the page's content for the Point's popup, we could introduce a new class
> property popupContent and have the popup content inside that. This way, we
> can use WYSIWYG as well.
>
> Another approach could be to keep the current Point Editor and use that
> create points without any sheet.
>
> The same questions apply for the Shape Editor as well.
> What do you think?
>
> Best,
> Fawad
>
>
> On Fri, Aug 2, 2019 at 2:53 PM Fawad Ali  wrote:
>
>> Stéphane,
>>
>> Yes, sure.
>> In the meantime, I will be working on the PointSheet.
>> However, I do want to ask if the Shape Editor is necessary at this point
>> if we are going with GeoJSON. We can refer the user to http://geojson.io
>> for creating the features. What do you think?
>>
>> Best,
>> Fawad
>>
>>
>> On Fri, Aug 2, 2019 at 12:04 PM Stéphane Laurière 
>> wrote:
>>
>>> OK Fawad,
>>>
>>> Meantime since Caty is off, and since today might actually be a bit
>>> early for me I'm afraid, I'd propose we have the call on Monday 15:00 UTC
>>> on Monday if that's ok with you .
>>>
>>> Cheers
>>>
>>> Stéphane
>>>
>>>
>>> Fawad Ali:
>>> > Stéphane, Ecaterina,
>>> >
>>> > About the call, I think we should have it so that we all converge on
>>> the things to be done.
>>> > However, tomorrow (Friday), I have a call with the Pakistan's GSoC
>>> community at about 5 PM UTC. If the call will be finished in two hours I am
>>> fine with it or we could reschedule it to 2:30 PM UTC or else Monday.
>>> >
>>> > Best,
>>>
>>>
>>> --
>>> Stéphane Laurière
>>> XWiki – https://xwiki.com
>>>
>>>

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

2019-08-02 Thread Stéphane Laurière


Fawad,

One option to do this is to use the ready-made AppWithinMinutes editors, by introducing 
an additional field for the content in a class, and filling in the custom displayer 
property value with "{{include reference='AppWithinMinutes.Content'/}}". You 
can use the same approach for editing the page title from an XWikiObject form. I could 
not find an online documentation about this feature yet, we might document it in greater 
details as it's very handy when the need arises to combine the document and the object 
approaches.

Cheers

Stéphane


Hi all,

I wanted to ask if it was possible to have a custom class sheet and the editing 
options of a normal page available at the same time?
As it stands, for the PointSheet, we will have to skip the WYSIWYG editor for 
editing the page. However, one thing could be that instead of taking the page's 
content for the Point's popup, we could introduce a new class property 
popupContent and have the popup content inside that. This way, we can use 
WYSIWYG as well.

Another approach could be to keep the current Point Editor and use that create 
points without any sheet.

The same questions apply for the Shape Editor as well.
What do you think?

Best,
Fawad

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

2019-08-02 Thread Fawad Ali

Hi all,

I wanted to ask if it was possible to have a custom class sheet and the
editing options of a normal page available at the same time?
As it stands, for the PointSheet, we will have to skip the WYSIWYG editor
for editing the page. However, one thing could be that instead of taking
the page's content for the Point's popup, we could introduce a new class
property popupContent and have the popup content inside that. This way, we
can use WYSIWYG as well.

Another approach could be to keep the current Point Editor and use that
create points without any sheet.

The same questions apply for the Shape Editor as well.
What do you think?

Best,
Fawad

On Fri, Aug 2, 2019 at 2:53 PM Fawad Ali  wrote:

> Stéphane,
>
> Yes, sure.
> In the meantime, I will be working on the PointSheet.
> However, I do want to ask if the Shape Editor is necessary at this point
> if we are going with GeoJSON. We can refer the user to http://geojson.io
> for creating the features. What do you think?
>
> Best,
> Fawad
>
>
> On Fri, Aug 2, 2019 at 12:04 PM Stéphane Laurière 
> wrote:
>
>> OK Fawad,
>>
>> Meantime since Caty is off, and since today might actually be a bit early
>> for me I'm afraid, I'd propose we have the call on Monday 15:00 UTC on
>> Monday if that's ok with you .
>>
>> Cheers
>>
>> Stéphane
>>
>>
>> Fawad Ali:
>> > Stéphane, Ecaterina,
>> >
>> > About the call, I think we should have it so that we all converge on
>> the things to be done.
>> > However, tomorrow (Friday), I have a call with the Pakistan's GSoC
>> community at about 5 PM UTC. If the call will be finished in two hours I am
>> fine with it or we could reschedule it to 2:30 PM UTC or else Monday.
>> >
>> > Best,
>>
>>
>> --
>> Stéphane Laurière
>> XWiki – https://xwiki.com
>>
>>

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

2019-08-01 Thread Ecaterina Moraru (Valica)

Hi,

I am out of the country and won't have access to fast Internet in the
following 2 weeks, so I won't be able to participate in the call. Sorry.

Caty

On Thu, Aug 1, 2019 at 10:03 PM Fawad Ali  wrote:

> Stéphane, Ecaterina,
>
> About the call, I think we should have it so that we all converge on the
> things to be done.
> However, tomorrow (Friday), I have a call with the Pakistan's GSoC
> community at about 5 PM UTC. If the call will be finished in two hours I am
> fine with it or we could reschedule it to 2:30 PM UTC or else Monday.
>
> Best,
> Fawad
>
>
> On Thu, Aug 1, 2019 at 11:58 PM Fawad Ali  wrote:
>
>> Stéphane,
>>
>> Your suggestions regarding the Point Editor are also very helpful. I will
>> make a sheet for PointClass as it will be much better.
>> I will do the same with Shape Editor and ShapeClass as leaflet easily
>> converts map items to GeoJSON.
>>
>> Best,
>> Fawad
>>
>>
>> On Thu, Aug 1, 2019 at 11:54 PM Fawad Ali 
>> wrote:
>>
>>> Stéphane,
>>>
>>> I agree that GeoJSON would be a much portable and standard option. I
>>> went with the structure I implemented because I was directly working with
>>> leaflet docs.
>>> I have one concern though and that is the flexibility of GeoJSON. By
>>> flexibility I mean that it will be harder for XWiki users to get used to
>>> the GeoJSON as opposed to the "points" and "options" properties of
>>> ShapeClass. Nonetheless, I am going with the GeoJSON now.
>>>
>>> Best,
>>> Fawad
>>>
>>>
>>> On Thu, Aug 1, 2019 at 11:37 PM Stéphane Laurière 
>>> wrote:
>>>
 Fawad, Caty,

 I had mostly technical aspects in mind when proposing a call, I
 overlooked that UX and design also need to be discussed so that we make
 sure to align our views for the upcoming weeks. Let's see in a private
 channel how we can align our agenda to make this happen, if you feel like
 it. Apologies for having acted a bit in a rush.

 Cheers

 Stéphane


 > Hi all,
 >
 > The setup for shapes has been done.
 > What I have in mind now is to have a Shape Editor similar to the
 Point Editor with interactive tools to create shapes. Stephane, if you have
 anything else in mind for interactively creating shapes then please let me
 know so that we are on the same page.
 > I will work on it as fast as I can so we can move on to the
 implementation of Indoor Maps.
 >
 > Best,
 > Fawad Ali
 >
 >
 > On Tue, Jul 30, 2019 at 11:46 AM Stéphane Laurière <
 slauri...@xwiki.com > wrote:
 >
 > Hi Fawad,
 >
 > I would go for approach C as well, that is storing all shape data
 entirely in json, since most probably the shapes will either by imported
 directly from preexisting data in json or any equivalent, or drawn by hand
 on a map. I see no real use case yet for an intermediary input where part
 of the data would be entered via a form, then by hand. Query-wise, I don't
 think we will need to retrieve a huge quantity of shapes with any given
 property value that would need to break down some specific values into
 dedicated properties. In case we do some day, we could either build a
 dedicated index I would say, or fill in dedicated properties automatically
 from the json input via a listener.
 >
 > Cheers,
 >
 > Stéphane
 >
 >
 >  > Hi Stéphane, Ecaterina and everyone,
 >  > Hope you all had a wonderful weekend.
 >  >
 >  > So I am working on shapes and wanted to know how I should deal
 with the large number of options for each shape type. As expected, the
 options are different for each shape type.
 >  >
 >  > I have multiple approaches in mind for this:
 >  > *Approach A:* Using the normal properties of XClass, create
 all the options for a shape type as properties for that class. This will in
 turn increase the class size as a lot of options will exist for each shape
 type.
 >  > *Approach B:* Use a static list or array to define the value
 of each shape type option. I have tried and it seems we cannot make use of
 key value pairs in static list or any other data type in XWiki so I am not
 completely sure of the implementation using static lists.
 >  > *Approach C:* Create a single TextArea property for options in
 each shape type class. The user can pass a JSON of options in that
 TextArea. Imho I prefer this approach since JSON is a standard format and
 it will give the user freedom of which options to use.
 >  >
 >  > WDYT?
 >  >
 >  > Best,
 >  > Fawad Ali
 >


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

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

Stéphane, Ecaterina,

About the call, I think we should have it so that we all converge on the
things to be done.
However, tomorrow (Friday), I have a call with the Pakistan's GSoC
community at about 5 PM UTC. If the call will be finished in two hours I am
fine with it or we could reschedule it to 2:30 PM UTC or else Monday.

Best,
Fawad


On Thu, Aug 1, 2019 at 11:58 PM Fawad Ali  wrote:

> Stéphane,
>
> Your suggestions regarding the Point Editor are also very helpful. I will
> make a sheet for PointClass as it will be much better.
> I will do the same with Shape Editor and ShapeClass as leaflet easily
> converts map items to GeoJSON.
>
> Best,
> Fawad
>
>
> On Thu, Aug 1, 2019 at 11:54 PM Fawad Ali  wrote:
>
>> Stéphane,
>>
>> I agree that GeoJSON would be a much portable and standard option. I went
>> with the structure I implemented because I was directly working with
>> leaflet docs.
>> I have one concern though and that is the flexibility of GeoJSON. By
>> flexibility I mean that it will be harder for XWiki users to get used to
>> the GeoJSON as opposed to the "points" and "options" properties of
>> ShapeClass. Nonetheless, I am going with the GeoJSON now.
>>
>> Best,
>> Fawad
>>
>>
>> On Thu, Aug 1, 2019 at 11:37 PM Stéphane Laurière 
>> wrote:
>>
>>> Fawad, Caty,
>>>
>>> I had mostly technical aspects in mind when proposing a call, I
>>> overlooked that UX and design also need to be discussed so that we make
>>> sure to align our views for the upcoming weeks. Let's see in a private
>>> channel how we can align our agenda to make this happen, if you feel like
>>> it. Apologies for having acted a bit in a rush.
>>>
>>> Cheers
>>>
>>> Stéphane
>>>
>>>
>>> > Hi all,
>>> >
>>> > The setup for shapes has been done.
>>> > What I have in mind now is to have a Shape Editor similar to the Point
>>> Editor with interactive tools to create shapes. Stephane, if you have
>>> anything else in mind for interactively creating shapes then please let me
>>> know so that we are on the same page.
>>> > I will work on it as fast as I can so we can move on to the
>>> implementation of Indoor Maps.
>>> >
>>> > Best,
>>> > Fawad Ali
>>> >
>>> >
>>> > On Tue, Jul 30, 2019 at 11:46 AM Stéphane Laurière <
>>> slauri...@xwiki.com > wrote:
>>> >
>>> > Hi Fawad,
>>> >
>>> > I would go for approach C as well, that is storing all shape data
>>> entirely in json, since most probably the shapes will either by imported
>>> directly from preexisting data in json or any equivalent, or drawn by hand
>>> on a map. I see no real use case yet for an intermediary input where part
>>> of the data would be entered via a form, then by hand. Query-wise, I don't
>>> think we will need to retrieve a huge quantity of shapes with any given
>>> property value that would need to break down some specific values into
>>> dedicated properties. In case we do some day, we could either build a
>>> dedicated index I would say, or fill in dedicated properties automatically
>>> from the json input via a listener.
>>> >
>>> > Cheers,
>>> >
>>> > Stéphane
>>> >
>>> >
>>> >  > Hi Stéphane, Ecaterina and everyone,
>>> >  > Hope you all had a wonderful weekend.
>>> >  >
>>> >  > So I am working on shapes and wanted to know how I should deal
>>> with the large number of options for each shape type. As expected, the
>>> options are different for each shape type.
>>> >  >
>>> >  > I have multiple approaches in mind for this:
>>> >  > *Approach A:* Using the normal properties of XClass, create all
>>> the options for a shape type as properties for that class. This will in
>>> turn increase the class size as a lot of options will exist for each shape
>>> type.
>>> >  > *Approach B:* Use a static list or array to define the value of
>>> each shape type option. I have tried and it seems we cannot make use of key
>>> value pairs in static list or any other data type in XWiki so I am not
>>> completely sure of the implementation using static lists.
>>> >  > *Approach C:* Create a single TextArea property for options in
>>> each shape type class. The user can pass a JSON of options in that
>>> TextArea. Imho I prefer this approach since JSON is a standard format and
>>> it will give the user freedom of which options to use.
>>> >  >
>>> >  > WDYT?
>>> >  >
>>> >  > Best,
>>> >  > Fawad Ali
>>> >
>>>
>>>
>>> --
>>> Stéphane Laurière
>>> XWiki – https://xwiki.com
>>>
>>>

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

Stéphane,

Your suggestions regarding the Point Editor are also very helpful. I will
make a sheet for PointClass as it will be much better.
I will do the same with Shape Editor and ShapeClass as leaflet easily
converts map items to GeoJSON.

Best,
Fawad


On Thu, Aug 1, 2019 at 11:54 PM Fawad Ali  wrote:

> Stéphane,
>
> I agree that GeoJSON would be a much portable and standard option. I went
> with the structure I implemented because I was directly working with
> leaflet docs.
> I have one concern though and that is the flexibility of GeoJSON. By
> flexibility I mean that it will be harder for XWiki users to get used to
> the GeoJSON as opposed to the "points" and "options" properties of
> ShapeClass. Nonetheless, I am going with the GeoJSON now.
>
> Best,
> Fawad
>
>
> On Thu, Aug 1, 2019 at 11:37 PM Stéphane Laurière 
> wrote:
>
>> Fawad, Caty,
>>
>> I had mostly technical aspects in mind when proposing a call, I
>> overlooked that UX and design also need to be discussed so that we make
>> sure to align our views for the upcoming weeks. Let's see in a private
>> channel how we can align our agenda to make this happen, if you feel like
>> it. Apologies for having acted a bit in a rush.
>>
>> Cheers
>>
>> Stéphane
>>
>>
>> > Hi all,
>> >
>> > The setup for shapes has been done.
>> > What I have in mind now is to have a Shape Editor similar to the Point
>> Editor with interactive tools to create shapes. Stephane, if you have
>> anything else in mind for interactively creating shapes then please let me
>> know so that we are on the same page.
>> > I will work on it as fast as I can so we can move on to the
>> implementation of Indoor Maps.
>> >
>> > Best,
>> > Fawad Ali
>> >
>> >
>> > On Tue, Jul 30, 2019 at 11:46 AM Stéphane Laurière > > wrote:
>> >
>> > Hi Fawad,
>> >
>> > I would go for approach C as well, that is storing all shape data
>> entirely in json, since most probably the shapes will either by imported
>> directly from preexisting data in json or any equivalent, or drawn by hand
>> on a map. I see no real use case yet for an intermediary input where part
>> of the data would be entered via a form, then by hand. Query-wise, I don't
>> think we will need to retrieve a huge quantity of shapes with any given
>> property value that would need to break down some specific values into
>> dedicated properties. In case we do some day, we could either build a
>> dedicated index I would say, or fill in dedicated properties automatically
>> from the json input via a listener.
>> >
>> > Cheers,
>> >
>> > Stéphane
>> >
>> >
>> >  > Hi Stéphane, Ecaterina and everyone,
>> >  > Hope you all had a wonderful weekend.
>> >  >
>> >  > So I am working on shapes and wanted to know how I should deal
>> with the large number of options for each shape type. As expected, the
>> options are different for each shape type.
>> >  >
>> >  > I have multiple approaches in mind for this:
>> >  > *Approach A:* Using the normal properties of XClass, create all
>> the options for a shape type as properties for that class. This will in
>> turn increase the class size as a lot of options will exist for each shape
>> type.
>> >  > *Approach B:* Use a static list or array to define the value of
>> each shape type option. I have tried and it seems we cannot make use of key
>> value pairs in static list or any other data type in XWiki so I am not
>> completely sure of the implementation using static lists.
>> >  > *Approach C:* Create a single TextArea property for options in
>> each shape type class. The user can pass a JSON of options in that
>> TextArea. Imho I prefer this approach since JSON is a standard format and
>> it will give the user freedom of which options to use.
>> >  >
>> >  > WDYT?
>> >  >
>> >  > Best,
>> >  > Fawad Ali
>> >
>>
>>
>> --
>> Stéphane Laurière
>> XWiki – https://xwiki.com
>>
>>

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

Stéphane,

I agree that GeoJSON would be a much portable and standard option. I went
with the structure I implemented because I was directly working with
leaflet docs.
I have one concern though and that is the flexibility of GeoJSON. By
flexibility I mean that it will be harder for XWiki users to get used to
the GeoJSON as opposed to the "points" and "options" properties of
ShapeClass. Nonetheless, I am going with the GeoJSON now.

Best,
Fawad


On Thu, Aug 1, 2019 at 11:37 PM Stéphane Laurière 
wrote:

> Fawad, Caty,
>
> I had mostly technical aspects in mind when proposing a call, I overlooked
> that UX and design also need to be discussed so that we make sure to align
> our views for the upcoming weeks. Let's see in a private channel how we can
> align our agenda to make this happen, if you feel like it. Apologies for
> having acted a bit in a rush.
>
> Cheers
>
> Stéphane
>
>
> > Hi all,
> >
> > The setup for shapes has been done.
> > What I have in mind now is to have a Shape Editor similar to the Point
> Editor with interactive tools to create shapes. Stephane, if you have
> anything else in mind for interactively creating shapes then please let me
> know so that we are on the same page.
> > I will work on it as fast as I can so we can move on to the
> implementation of Indoor Maps.
> >
> > Best,
> > Fawad Ali
> >
> >
> > On Tue, Jul 30, 2019 at 11:46 AM Stéphane Laurière  > wrote:
> >
> > Hi Fawad,
> >
> > I would go for approach C as well, that is storing all shape data
> entirely in json, since most probably the shapes will either by imported
> directly from preexisting data in json or any equivalent, or drawn by hand
> on a map. I see no real use case yet for an intermediary input where part
> of the data would be entered via a form, then by hand. Query-wise, I don't
> think we will need to retrieve a huge quantity of shapes with any given
> property value that would need to break down some specific values into
> dedicated properties. In case we do some day, we could either build a
> dedicated index I would say, or fill in dedicated properties automatically
> from the json input via a listener.
> >
> > Cheers,
> >
> > Stéphane
> >
> >
> >  > Hi Stéphane, Ecaterina and everyone,
> >  > Hope you all had a wonderful weekend.
> >  >
> >  > So I am working on shapes and wanted to know how I should deal
> with the large number of options for each shape type. As expected, the
> options are different for each shape type.
> >  >
> >  > I have multiple approaches in mind for this:
> >  > *Approach A:* Using the normal properties of XClass, create all
> the options for a shape type as properties for that class. This will in
> turn increase the class size as a lot of options will exist for each shape
> type.
> >  > *Approach B:* Use a static list or array to define the value of
> each shape type option. I have tried and it seems we cannot make use of key
> value pairs in static list or any other data type in XWiki so I am not
> completely sure of the implementation using static lists.
> >  > *Approach C:* Create a single TextArea property for options in
> each shape type class. The user can pass a JSON of options in that
> TextArea. Imho I prefer this approach since JSON is a standard format and
> it will give the user freedom of which options to use.
> >  >
> >  > WDYT?
> >  >
> >  > Best,
> >  > Fawad Ali
> >
>
>
> --
> Stéphane Laurière
> XWiki – https://xwiki.com
>
>

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

2019-08-01 Thread Stéphane Laurière

Fawad, Caty,

I had mostly technical aspects in mind when proposing a call, I overlooked that 
UX and design also need to be discussed so that we make sure to align our views 
for the upcoming weeks. Let's see in a private channel how we can align our 
agenda to make this happen, if you feel like it. Apologies for having acted a 
bit in a rush.

Cheers

Stéphane

Hi all,

The setup for shapes has been done.
What I have in mind now is to have a Shape Editor similar to the Point Editor 
with interactive tools to create shapes. Stephane, if you have anything else in 
mind for interactively creating shapes then please let me know so that we are 
on the same page.
I will work on it as fast as I can so we can move on to the implementation of 
Indoor Maps.

Best,
Fawad Ali

On Tue, Jul 30, 2019 at 11:46 AM Stéphane Laurière mailto:slauri...@xwiki.com>> wrote:

Hi Fawad,

I would go for approach C as well, that is storing all shape data entirely 
in json, since most probably the shapes will either by imported directly from 
preexisting data in json or any equivalent, or drawn by hand on a map. I see no 
real use case yet for an intermediary input where part of the data would be 
entered via a form, then by hand. Query-wise, I don't think we will need to 
retrieve a huge quantity of shapes with any given property value that would 
need to break down some specific values into dedicated properties. In case we 
do some day, we could either build a dedicated index I would say, or fill in 
dedicated properties automatically from the json input via a listener.

Cheers,

Stéphane

 > Hi Stéphane, Ecaterina and everyone,
 > Hope you all had a wonderful weekend.
 >
 > So I am working on shapes and wanted to know how I should deal with the 
large number of options for each shape type. As expected, the options are 
different for each shape type.
 >
 > I have multiple approaches in mind for this:
 > *Approach A:* Using the normal properties of XClass, create all the 
options for a shape type as properties for that class. This will in turn increase 
the class size as a lot of options will exist for each shape type.
 > *Approach B:* Use a static list or array to define the value of each 
shape type option. I have tried and it seems we cannot make use of key value pairs 
in static list or any other data type in XWiki so I am not completely sure of the 
implementation using static lists.
 > *Approach C:* Create a single TextArea property for options in each 
shape type class. The user can pass a JSON of options in that TextArea. Imho I 
prefer this approach since JSON is a standard format and it will give the user 
freedom of which options to use.
 >
 > WDYT?
 >
 > Best,
 > Fawad Ali

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

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

2019-08-01 Thread Stéphane Laurière

Hi Fawad,

Thanks for the update. I had a look at the ShapeClass and I have a remark about their structure. I
see you introduced the properties "points", "type". I'm wondering whether we
could simply consider that the shapes are entirely represented in GeoJSON, including the style
options, just like http://geojson.io/ behaves, eg in the example below. What would be the use case
for storing these properties separately? I thought your previous question were about that, sorry
for the misunderstanding.

Regarding the editors: good to see there's the point editor (I had not tried it
yet), I have some remarks about it:
- What about setting it up by default for the PointClass objects, so that these
points can be edited using the editor, by creating a PointSheet that uses it?
- We could introduce a TemplateProvider for points, so that creating points can
be achieved using the standard XWiki create page, what do you think?
- What's the rationale for storing the editors in a dedicated space? I would
either put all them in the Code space directly, or in a subspace if you really
want to group them (I tend to avoid having too many nested spaces but that's a
personal taste only).

I may have other remarks that I will bring up directly on Jira if that's ok
with you.

It's good to read that you already have in mind indoor maps as it's a promising
feature imho, on the other hand I'd say there could be also much value in
improving the current features, I need to get my head around that and to review
the current issues. I will do so by tomorrow, then we could set up a call at
the end of the day, if possible for you, or on Monday. What about 3pm UTC
tomorrow? Or Monday 3pm UTC?

Cheers

Stéphane

{
"type": "Feature",
"properties": {
"stroke": "#c5ce00",
"stroke-width": 2,
"stroke-opacity": 1,
"fill": "#c13d3d",
"fill-opacity": 0.5
},
"geometry": {
"type": "Polygon",
"coordinates": [
[
[
148.7109375,
54.36775852406841
],
[
146.9531249997,
54.16243396806779
],
[
170.5078125,
6.664607562172573
],
[
216.2109375,
40.17887331434696
],
[
198.9843749997,
76.01609366420995
],
[
148.7109375,
54.36775852406841
]
]
]
}
}

Hi all,

The setup for shapes has been done.
What I have in mind now is to have a Shape Editor similar to the Point Editor
with interactive tools to create shapes. Stephane, if you have anything else in
mind for interactively creating shapes then please let me know so that we are
on the same page.
I will work on it as fast as I can so we can move on to the implementation of
Indoor Maps.

Best,
Fawad Ali
--

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

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