Makes sense. If it eliminates the use of quad tree completely, which I think is
a subscriptions based product, it would be a saving. If it's a legacy system
with no subscription element, leave it as a place holder.Sent from Samsung
Mobile on O2
-------- Original message --------From: Martin Desruisseaux
<martin.desruisse...@geomatys.com> Date: 13/01/2020 10:21 (GMT+00:00) To:
dev@sis.apache.org Subject: Re: Proposal to remove (for now) the sis-webapp
module Hello ShahjahanLe 12/01/2020 à 18:52, Shahjahan Ahmed a écrit :> Before
removing it. Does anyone know what the app was designed for?A description is
available on the wiki at [1]. My understanding it that user enters coordinates
of a bounding box and the application shows locations (maybe with additional
info) of some points in that bounding box, with GeoRSS as the source of those
points. But I think it has never been an application working "out of the box".
The files in the WEB-INF and META-INF directories are values like
"/path/to/sis-location-config.xml" [2], "/path/to/qtree/index/dir",
"/path/to/georss/xml/files/dir" [2][3], apparently expecting a developer to
edit those paths and build locally. After the paths have been set, the
application reads a list of URLs of GeoRSS sources [4]. The links listed in
this file seem dead now, so I can not check the data format. The results were
shown in a JSP page which imports CSS and JavaScript from
http://leaflet.cloudmade.com (maybe for showing the map) [5], but the
referenced resources do not seem to exist anymore. The whole Java code is a
single, relatively small Java file [6].The reason why I propose to remove
sis-webapp is because it is currently the only code in SIS which use QuadTree.
An issue has been raised recently on user mailing list [7] which requires a
QuadTree or RTree for proper resolution. So I though about using the existing
SIS QuadTree [8], but it is a "Point QuadTree" (storing only points) while
resolving the issue requires a "Region QuadTree" (storing bounding boxes). I
have also other concerns with that QuadTree (e.g. it works with
latitudes/longitudes only and uses a hard-coded Earth radius) which incited me
to put a warning in Javadoc saying that this class may change in future SIS
release. Now if we want to work on this QuadTree, the task would be a little
bit easier if we do not need to preserve compatibility with sis-webapp.Note: we
had a Google Summer of Code project 1~2 years ago about implementing an OGC
Catalog Service for the Web (CSW). This is a distinct sis-webapp than the one
I'm proposing to remove. The result of this GSoC project is still on a
separated repository for now [9]. My hope is still to use that GSoC work as a
starting point for a new application/sis-webapp module in the future.The
proposal is about removing the Java code, JSP page and configuration files, but
keep sis-webapp has an empty (for now) module ready to receive new work. The
removed sis-webapp still have value as an example of how to setup a small
server using Jetty and how to configure the tests. Martin[1]
https://cwiki.apache.org/confluence/display/SIS/Web+application[2]
https://github.com/apache/sis/blob/0.8/application/sis-webapp/src/main/webapp/WEB-INF/web.xml[3]
https://github.com/apache/sis/blob/0.8/application/sis-webapp/src/main/webapp/META-INF/context.xml[4]
https://github.com/apache/sis/blob/0.8/application/sis-webapp/src/main/resources/sis-location-config.xml[5]
https://github.com/apache/sis/blob/0.8/application/sis-webapp/src/main/webapp/demo.jsp[6]
https://github.com/apache/sis/blob/0.8/application/sis-webapp/src/main/java/org/apache/sis/services/LocationServlet.java[7]
https://lists.apache.org/thread.html/rfec61914fd6f5ce6798953aeea8c37d813408438021ec5626da40500%40%3Cuser.sis.apache.org%3E[8]
http://sis.apache.org/apidocs/org/apache/sis/index/tree/QuadTree.html[9]
https://github.com/haonguyen123/sis/tree/CSW
