Feature #839

Indoor navigation

Added by Magoni Bruno almost 5 years ago. Updated about 4 years ago.

Status:ClosedStart date:10/20/2014
Priority:NormalDue date:
Assignee:-% Done:

100%

Category:MAP
Target version:4.3.0
Sponsor: Ergonomic impact:
Functional impact:

Description

Beside outdoor information, indoor navigation is also a great consumer of maps through building/level principle (which is not 3D!).

Goal of indoor navigation is to display geographical information of buildings equipment (like premises, doors, corridors, ...) into a map context, mixing it with outdoor classical information.

Proposal is to add a new "indoor" tool for map context definition.
If such tool is used, backoffice will ask for:
  • the default level which is displayed when opening the map
  • the list of all potential levels that a user can select into the map
Levels are defined through label/code parameters:
  • label will be displayed into the map through a levels selector (same as a zoom selector)
  • corresponding code will be sent through WMS filtering to any OGC server to recover indoor information of a specific level for all buildings

Backoffice interface will also contain a new parameter for layers which expose indoor information: the name of the WMS attribute which stores level information for such layer

Inside a map, the user will be able to change the current displayed level. Only layers which are concerned by indoor navigation will be refreshed.

As WMS filtering is a vendor specific functionality, easySDI will ask for each indoor layer the kind of OGC server which deliver such data: GeoServer or ArcGISserver
Even if CQL is a common ways to filter WMS server, GeoServer and ArcGI Server have got some implementation differences about how to send WMS filter parameters.
Front office Map will then send the correct WMS Filter CQL definition regarding the targeted OGC server.
Levels selector will be developed with GeoExt LayerOpacitySlider which overloads Ext.slider.SingleSlider


Related issues

Related to easySDI - Feature #846: Enhancement of WFS location engine Rejected 10/20/2014

History

#1 Updated by Magoni Bruno almost 5 years ago

  • Related to Feature #846: Enhancement of WFS location engine added

#2 Updated by Portier Thomas almost 5 years ago

For this kind of advanced feature, I don't believe that it should be included in the trunk of EasySDI.
I also think that the actual technology used for the actual map is outdated.

We developped a new map fed with layers configured in EasySDI but rendered in leaflet : https://test.geoplateforme17.fr/cadastre
This development could be added as a new Map view in EasySDI.

Instead of adding new features to the actual geoext Map, I think it would be better to propose a leaflet Map that could be overwritten easyly to add new features (as indoor navigation).

Some implementations of indoor maps with leaflet :
http://osmtools.org/indoor/#lat=51.09447&lon=17.01945&z=18
http://cbaines.github.io/leaflet-indoor/examples/

#3 Updated by Magoni Bruno almost 5 years ago

Hi Thomas,

Thanks for your feedback which is very interesting.
I see two main points under your last notice:

1. current feature should not be added in MAP component
As such feature is proposed as a new MAP tool, the benefit is that any MAP context can potentially benefit of all tools; my opinion is that viewing data through an INSIPRE compliant tool like easySDI must integrate several kind of data (like 2D & 3D for outdoor and indoor context). For example, printing a MAP must apply to any kind of data and I prefer maintaining one global component then several with different "data kind" approach

2. Community must think about new MAP technologies
I totally agree with you and have added such discussion point in the next Technical Committee session.
The approach of using new technology for business specific need (like you did it for territorial survey) is a good one as experience can be made without involving trunk.
But changing core API (in this case for MAP extension) still need to be carefully embraced in a global manner (loose of current functionalities, backward compatibility, stability, and so on).

This current feature has been discussed yesterday in Steering Committee because there is some "urgency" about realizing it.
Steering Committee has decided to go ahead with such proposed feature and keep it in trunk for several strategic reasons.
Such situation reveals that talking about MAP API is a hot topic with OL3 new release and Leaflet new kid of the block !

#4 Updated by Portier Thomas almost 5 years ago

My opinion is that indoor navigation must be rendered with vector features for two reasons :
- Each building have a different level number. With your approach, the user will be able to ask the same levels for all buildings
- The user doesn't care about just viewing a level as an image but he wants to have informations about the rooms in the level. It's easier and faster to do it with a vector layer

A good example here : http://clement-lagrange.github.io/osmtools-indoor/

About technologies, my proposition is not to abandon the GeoExt version of the Map but to add a new type of map based on Leaflet. It could be a parameter in back-end : MapType GeoExt/Leaflet. If the user chooses Leaflet, he will have less tools than the Geoext one.

#6 Updated by Magoni Bruno almost 5 years ago

  • Target version set to 158

#7 Updated by Magoni Bruno almost 5 years ago

  • Priority changed from Normal to Urgent

#8 Updated by Magoni Bruno almost 5 years ago

  • Status changed from Request For Comments to Request For Votes
  • Assignee changed from Technical Committee to Steering Committee
  • Priority changed from Urgent to Normal

TC agree about integrating indoor navigation inside current MAP version and ask SC to define which kind of features should be delivered by MAP component.
The strategic way will help choice of new APIs which can be used for new MAP version (i.e. OL3, Leaflet, ...)

#9 Updated by Magoni Bruno almost 5 years ago

  • Status changed from Request For Votes to Accepted
  • Assignee deleted (Steering Committee)

#10 Updated by Magoni Bruno almost 5 years ago

  • Status changed from Accepted to Affected
  • Assignee set to Van Hoecke Hélène

#11 Updated by Magoni Bruno over 4 years ago

  • Target version changed from 158 to 4.3.0

#12 Updated by Van Hoecke Hélène over 4 years ago

  • Status changed from Affected to Resolved

#13 Updated by Van Hoecke Hélène over 4 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100

#14 Updated by Van Hoecke Hélène about 4 years ago

  • Assignee deleted (Van Hoecke Hélène )

Also available in: Atom PDF