Opened 12 years ago
Closed 5 years ago
#388 closed enhancement (wontfix)
Add constraints on compound CRSs
Reported by: | Piero Campalani | Owned by: | Dimitar Misev |
---|---|---|---|
Priority: | minor | Milestone: | Future |
Component: | secore | Version: | 8.4 |
Keywords: | secore constraints compound | Cc: | Peter Baumann |
Complexity: | Medium |
Description
There are known constraints when compounding CRSs, in the geospatial context.
SECORE should inhibit the composition of incompatible CRSs, and in the first place of identical CRSs:
http://kahlua.eecs.jacobs-university.de:8080/def/crs-compound?
1=http://kahlua.eecs.jacobs-university.de:8080/def/crs/EPSG/0/4327&
2=http://kahlua.eecs.jacobs-university.de:8080/def/crs/EPSG/0/4327
The possible compounding include:
- Geographic 2D + Vertical
- Geographic 2D + Engineering 1D (near vertical)
- Projected + Vertical
- Projected + Engineering 1D (near vertical)
- Engineering (horizontal 2D) + Vertical
- Engineering (1D linear) + Vertical
Change History (13)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Yes it is limiting, but I meant to check validity of CCRS with regards to the geospatial ones:, which should be:
gml:ProjectedCRS
gml:GeodeticCRS
gml:VerticalCRS
gml:EngineeringCRS
gml:GeographicCRS
gml:GeocentricCRS
Then e.g. gml:TemporalCRS
can be appended anywhere.
comment:3 by , 11 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 9 years ago
Owner: | changed from | to
---|
comment:5 by , 9 years ago
This ticket covers this ticket http://www.rasdaman.org/ticket/150, so I will do this ticket as soon as I understand it correctly. My question is, I've seen one can create 5D coverages with compound from 4 "CRS" (GeodeticCRS + TemporalCRS + VerticalCRS + Vertical CRS), is it valid with regard to ISO 19111? or are duplicated compound CRS (2 Vertical CRS) are valid?
http://localhost:9090/def/crs-compound? 1=http://localhost:9090/def/crs/EPSG/0/4326 &2=http://localhost:9090/def/crs/OGC/0/AnsiDate &3=http://localhost:9090/def/crs/OGC/0/Index1D?axis-label="elev" &4=http://localhost:9090/def/crs/OGC/0/Index1D?axis-label="sensor";
comment:6 by , 9 years ago
Let's skip this one for the moment, it definitely needs to be discussed first.
comment:8 by , 9 years ago
Cc: | added; removed |
---|---|
Owner: | changed from | to
@Bang: this is the ticket you mixed up with #150. Note my earlier comment:
Let's skip this one for the moment, it definitely needs to be discussed first.
comment:9 by , 9 years ago
@Dimitar:
I've known this ticket before I did in ticket 150 and I think this ticket should be discussed clearly (as you pointed out).
Beside my earlier comments (#5), There is a new type of gml:CompoundCRS http://www.rasdaman.org/ticket/679 and this makes me confuse about the combination of this CRS type instead of concatenating from single CRS as ticket description.
comment:10 by , 9 years ago
Regarding #670 - that is not a new type, it's the same old compound CRS (same definition structure), but it has an official CRS code. In petascope we most often generate a compound CRS on the fly with crs-compound, which then doesn't have an official code. #670 is about enabling petascope to support the officially defined compound CRSs, those that do not have crs-compound in the URL.
comment:11 by , 8 years ago
Milestone: | 9.0.x → Future |
---|
comment:12 by , 8 years ago
this is an interesting field for geoinformatics, but no agreed solution available on which we can build. I tried that initially and modestly in OGC and was pointed out that such a thing does not fly. There is no known set of rules. Also, we have much more pertinent tasks.
comment:13 by , 5 years ago
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
Yes I know about the definitions (also in ISO 19111), but isn't that a bit limiting? It gives max 3D compound CRS.