Opened 5 years ago

Closed 5 years ago

#183 closed enhancement (fixed)

SECORE only recognizes URN identifiers of new uploaded definitions

Reported by: pcampalani Owned by: msahakyan
Priority: minor Milestone: 8.4
Component: secore Version: 8.3
Keywords: Cc:
Complexity: Medium


When uploading new CRS definitions to SECORE, the correct {authority,version,code} are understood if set in URN format, like:

<gml:GeographicCRS gml:id="ogrcrs1">
  <identifier codeSpace="OGP">urn:ogc:def:crs:FOO::1</identifier>
  <gml:srsName>My Ellipse</gml:srsName>
    <gml:EllipsoidalCS gml:id="ogrcrs2">

will properly be accessible at http://host:port/def/crs/FOO/0/1, but providing instead a URI identifier like:

<identifier codeSpace="OGP">http://host:port/def/crs/FOO/0/1</identifier>

will not work.

Change History (7)

comment:1 Changed 5 years ago by dmisev

  • Owner changed from mrusu to msahakyan
  • Status changed from new to assigned

SECORE is in applications/secore, you can open secore-core and secore-web in NetBeans? directly.

To deploy SECORE you can run the applications/secore/deploy script. It's best to download Tomcat from the website, instead of installing from the Ubuntu repos.

comment:2 Changed 5 years ago by pcampalani

Not really sure that this is a valid bug however.
URN notation does not allow for GML elements with an identifier contained in a definition to move away to an other host.
This is instead possible with URL:

<gml:GeographicCRS gml:id="ogrcrs1">
  <identifier codeSpace="OGP">http://localhost:8080/def/crs/XXX/0/MyCRS</identifier>
  <gml:srsName>My Ellipse</gml:srsName>
    <gml:EllipsoidalCS gml:id="ogrcrs2">
      <gml:identifier codeSpace="OGP"></gml:identifier>

I don't know if this is good behavior: when you define a new definition with new custom elements, they are added to the database where SECORE is, not where the URL points to.
URN seems to me better, it can avoid these kind of conflicts.


comment:3 Changed 5 years ago by dmisev

I guess the right way would be for secore to be able to properly resolve any URL, irrelevant of whether it's in the same database as the definition itself or not. This only affects the flattening of definitions, I can't remember if the URLs are properly resolved or directly looked up in the database.

comment:4 Changed 5 years ago by dmisev

Probably we should add some check, to test that the identifier actually points to the secore where the definition is being added, and reject if it doesn't.

comment:5 Changed 5 years ago by pbaumann

  • Milestone set to 9.0
  • Version set to 8.3

comment:6 Changed 5 years ago by dmisev

  • Complexity set to Medium
  • Milestone changed from 9.0 to 8.4

Submitted patch

comment:7 Changed 5 years ago by dmisev

  • Resolution set to fixed
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.