Map Application - GSoC 19

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

Re: Map Application - GSoC 19

vmassol
Administrator
Well done Fawad, congrats!

A very small detail: we’re strying to have the same styles for images on xwiki.org and we have some guidelines linked from https://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HDocumenting

For example for images here are the best practices:
https://dev.xwiki.org/xwiki/bin/view/Community/DocGuide#HScreenshots2FImages

So it would be awesome if you could use the {{image}} macro.

Thanks
-Vincent

> On 16 Jul 2019, at 19:27, Fawad Ali <[hidden email]> wrote:
>
> Hi all,
> Hope you are doing wonderful today.
>
> I am very excited to announce that Interaction Maps Application v1.0 is now
> up.
>
> Extension and documentation:
> https://extensions.xwiki.org/xwiki/bin/view/Extension/InteractiveMapsApplication/
> Forum post:
> https://forum.xwiki.org/t/interactive-maps-application-v1-0-released/
>
> Thanks to Thomas for helping with issues in the release; Stephane for all
> the wonderful and detailed instructions; Ecaterina for all the great help
> and ideas; Vincent for helping with tests and other issues; and everyone
> else who helped with the project.
> It has been a wonderful experience so far to work with the XWiki community!
> I look forward to how the complete application will turn out.
>
> Best,
> Fawad
>
>
> On Tue, Jul 16, 2019 at 1:31 PM Stéphane Laurière <[hidden email]>
> wrote:
>
>> Hi Fawad,
>>
>>> Also, I looked into it and the idea of custom class property for getting
>> the location is interesting indeed. I will see how I should prioritize it
>> and implement it then since we have other major features to look into.
>>>
>>> I would also like to ask; what do you foresee as the basic elements of
>> the application? We have map configuration, map query, search and filter
>> widget, markers and popups so far. Do you have anything other than this in
>> mind that could be thought of as the basis of the application? I think we
>> should completely stabilize the basics by the end of this week so I can
>> work on other features like map paths, indoor maps and custom shapes.
>>
>> Just a quick reply about this to confirm that I think the basic elements
>> that you mention form the core of version 1.0. I don't have much to add at
>> the moment. You're right that it's important to have sound foundations and
>> we should limit future modifications of the core as much as possible,
>> however despite anticipating the best we can, we may encounter the need to
>> modify it at some point, let's see...
>>
>> I saw you were facing issues with the release and the signing part, I hope
>> we'll manage to solve them with the help of the community. Let's continue
>> the discussion until we find a fix..
>>
>> Cheers
>>
>> Stéphane
>>
>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Fawad Ali
Hi all,
Hope you are doing well.

Stephane proposed that there should be a change in the Point data
structure. I agree that latitude and longitude should be two distinct
fields but am not sure how we are going to accommodate geographical
addresses. Should we create a separate class for an address? But if we are
going to supply latitude and longitude to the map, we will need to process
the addresses in some way and store their lat and lng somewhere as a point
object.
I am going to put this on hold until we are in the clear.

I have also added support for using custom class properties as addresses to
feed to the map as points. This feature is available in the advanced
options of map configuration. For now, the properties should be given in
the form property.ClassPath.property_name e.g.
property.XWiki.XWikiUsers.address_en. This is inline with how solr
perceives properties.
Does anyone have any suggestions for making it easier to query a class
property? I will try to remove the need for the ending "_en" or "_string"
part since they can prove confusing in some contexts.

I will start moving on with the development and create a mechanism for
adding paths to the map.

Best,
Fawad


On Wed, Jul 17, 2019 at 12:22 PM Vincent Massol <[hidden email]> wrote:

> Well done Fawad, congrats!
>
> A very small detail: we’re strying to have the same styles for images on
> xwiki.org and we have some guidelines linked from
> https://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HDocumenting
>
> For example for images here are the best practices:
>
> https://dev.xwiki.org/xwiki/bin/view/Community/DocGuide#HScreenshots2FImages
>
> So it would be awesome if you could use the {{image}} macro.
>
> Thanks
> -Vincent
>
> > On 16 Jul 2019, at 19:27, Fawad Ali <[hidden email]> wrote:
> >
> > Hi all,
> > Hope you are doing wonderful today.
> >
> > I am very excited to announce that Interaction Maps Application v1.0 is
> now
> > up.
> >
> > Extension and documentation:
> >
> https://extensions.xwiki.org/xwiki/bin/view/Extension/InteractiveMapsApplication/
> > Forum post:
> > https://forum.xwiki.org/t/interactive-maps-application-v1-0-released/
> >
> > Thanks to Thomas for helping with issues in the release; Stephane for all
> > the wonderful and detailed instructions; Ecaterina for all the great help
> > and ideas; Vincent for helping with tests and other issues; and everyone
> > else who helped with the project.
> > It has been a wonderful experience so far to work with the XWiki
> community!
> > I look forward to how the complete application will turn out.
> >
> > Best,
> > Fawad
> >
> >
> > On Tue, Jul 16, 2019 at 1:31 PM Stéphane Laurière <[hidden email]>
> > wrote:
> >
> >> Hi Fawad,
> >>
> >>> Also, I looked into it and the idea of custom class property for
> getting
> >> the location is interesting indeed. I will see how I should prioritize
> it
> >> and implement it then since we have other major features to look into.
> >>>
> >>> I would also like to ask; what do you foresee as the basic elements of
> >> the application? We have map configuration, map query, search and filter
> >> widget, markers and popups so far. Do you have anything other than this
> in
> >> mind that could be thought of as the basis of the application? I think
> we
> >> should completely stabilize the basics by the end of this week so I can
> >> work on other features like map paths, indoor maps and custom shapes.
> >>
> >> Just a quick reply about this to confirm that I think the basic elements
> >> that you mention form the core of version 1.0. I don't have much to add
> at
> >> the moment. You're right that it's important to have sound foundations
> and
> >> we should limit future modifications of the core as much as possible,
> >> however despite anticipating the best we can, we may encounter the need
> to
> >> modify it at some point, let's see...
> >>
> >> I saw you were facing issues with the release and the signing part, I
> hope
> >> we'll manage to solve them with the help of the community. Let's
> continue
> >> the discussion until we find a fix..
> >>
> >> Cheers
> >>
> >> Stéphane
> >>
> >>
> >>
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

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

> Hi all,
> Hope you are doing well.
>
> Stephane proposed that there should be a change in the Point data
> structure. I agree that latitude and longitude should be two distinct
> fields but am not sure how we are going to accommodate geographical
> addresses. Should we create a separate class for an address? But if we are
> going to supply latitude and longitude to the map, we will need to process
> the addresses in some way and store their lat and lng somewhere as a point
> object.
> I am going to put this on hold until we are in the clear.

I just commented on this at https://jira.xwiki.org/browse/INTMAP-27

> I have also added support for using custom class properties as addresses to
> feed to the map as points. This feature is available in the advanced
> options of map configuration. For now, the properties should be given in
> the form property.ClassPath.property_name e.g.
> property.XWiki.XWikiUsers.address_en. This is inline with how solr
> perceives properties.

That sounds great to use the same syntax as the Solr one indeed.

> Does anyone have any suggestions for making it easier to query a class
> property? I will try to remove the need for the ending "_en" or "_string"
> part since they can prove confusing in some contexts.

+1 for removing "_en" since the app could be used in wikis where English is not enabled. I don't have further suggestion on my end so far...

> I will start moving on with the development and create a mechanism for
> adding paths to the map.

Great, I commented also at https://jira.xwiki.org/browse/INTMAP-27 as you probably noticed,

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 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


On Mon, Jul 22, 2019 at 10:25 PM Stéphane Laurière <[hidden email]>
wrote:

> Hi Fawad, Hi all,
>
> > Hi all,
> > Hope you are doing well.
> >
> > Stephane proposed that there should be a change in the Point data
> > structure. I agree that latitude and longitude should be two distinct
> > fields but am not sure how we are going to accommodate geographical
> > addresses. Should we create a separate class for an address? But if we
> are
> > going to supply latitude and longitude to the map, we will need to
> process
> > the addresses in some way and store their lat and lng somewhere as a
> point
> > object.
> > I am going to put this on hold until we are in the clear.
>
> I just commented on this at https://jira.xwiki.org/browse/INTMAP-27
>
> > I have also added support for using custom class properties as addresses
> to
> > feed to the map as points. This feature is available in the advanced
> > options of map configuration. For now, the properties should be given in
> > the form property.ClassPath.property_name e.g.
> > property.XWiki.XWikiUsers.address_en. This is inline with how solr
> > perceives properties.
>
> That sounds great to use the same syntax as the Solr one indeed.
>
> > Does anyone have any suggestions for making it easier to query a class
> > property? I will try to remove the need for the ending "_en" or "_string"
> > part since they can prove confusing in some contexts.
>
> +1 for removing "_en" since the app could be used in wikis where English
> is not enabled. I don't have further suggestion on my end so far...
>
> > I will start moving on with the development and create a mechanism for
> > adding paths to the map.
>
> Great, I commented also at https://jira.xwiki.org/browse/INTMAP-27 as you
> probably noticed,
>
> 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
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

Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

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

Re: Map Application - GSoC 19

Stéphane Laurière-6
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.95312499999997,
               54.16243396806779
             ],
             [
               170.5078125,
               6.664607562172573
             ],
             [
               216.2109375,
               40.17887331434696
             ],
             [
               198.98437499999997,
               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

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,

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 <[hidden email] <mailto:[hidden email]>> 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

Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

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

Re: Map Application - GSoC 19

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

Re: Map Application - GSoC 19

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,
Fawad


On Thu, Aug 1, 2019 at 11:58 PM Fawad Ali <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> 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 <
>>> [hidden email] <mailto:[hidden email]>> 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
>>>
>>>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

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

Re: Map Application - GSoC 19

Fawad Ali
In reply to this post by 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 <[hidden email]> 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 <[hidden email]>
> 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
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Stéphane Laurière-6
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
>

Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Fawad Ali
In reply to this post by 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> 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
>>>
>>>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Stéphane Laurière-6
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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

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

Re: Map Application - GSoC 19

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

Re: Map Application - GSoC 19

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

Re: Map Application - GSoC 19

Stéphane Laurière-6
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

1234567