Ticket #108 (closed issue: duplicate)

Opened 14 years ago

Last modified 14 years ago

Non-contiguous coordinate systems

Reported by: selatham Owned by: domlowe
Priority: discussion Milestone: PreBeta
Component: CSML Version:
Keywords: Cc:

Description (last modified by domlowe) (diff)

CSML v2 feature types

Change History

comment:1 Changed 14 years ago by selatham

Dom says:- Yes, if you mean can you represent the coordinate axes using fileextract objects. (By non-contiguous in this sense I am interpreting that as irregularly spaced axis points.)

comment:2 Changed 14 years ago by domlowe

  • Status changed from new to assigned

comment:3 Changed 14 years ago by selatham

  • Cc rkl lawrence added; lawrence removed
  • Description modified (diff)

I think the example Roy gave of non-contiguous was a CTD profile which had regularly spaced points where measurements were made, but a gap in the middle somewhere for some reason. Roy - is that correct?

comment:4 Changed 14 years ago by rkl

Basically, we can have ANYTHING cropping up in our observational data holdings. Sometimes, co-ordinates are totally irregular (possibly even non-incremental if a CTD is deployed in very rough seas). Even if the co-ordinate is apparently 'regular' there is the possibility for there to be random gaps in the sequence where cycles have been deleted rather than being stuffed with null data values.

comment:5 Changed 14 years ago by rkl

Response from Dom

Rather than comment directly on Trac, I'm replying to the mailing list as this probably needs more discussion. ( http://proj.badc.rl.ac.uk/ndg/ticket/108)

As a general rule CSML can handle irregularities, as it can point to the raw data using 'file extracts' rather than relying on some formula to generate coordinates. So the answer to the original question (Can we use fileextract for non-contiguous coordinates?) is still yes.

However the limitation in some cases may be that the current set of feature types may not be sufficient to describe completely irregular datasets. So the answer is to create additional or better feature types within CSML.

Some things can be handled okay, eg missing times in a sequence. Whereas others can't be handled with the existing feature, e.g. the issue with non-uniform profile depths has already been identified, and the current ProfileSeries? feature in CSML can't handle these at the moment - you could instead model it as lots of separate profile features rather than one profile series feature but that might be the 'wrong' feature - so a new or improved feature type is needed.

So in short, irregularity itself isn't a problem for CSML but the feature type definitions may be limiting in some cases.

It would be good to look at some examples with you to discuss this in more detail before CSML "v2" feature types.

comment:6 Changed 14 years ago by rkl

Moved this discussion to trac, which is where I think it should be....

Totally agree with what Dom has said. File extract mechanism will be needed and a CSML feature type to cover a set of profiles having non-uniform depths is definitely required. The ability to model temperature and salinity from a cruise taken from CTD (profiles), thermosalinograph (trajectory confined to sea surface) and SeaSoar? (3-D trajectory) as a single CSML instance should be regarded as a desirable long-term aim.

comment:7 Changed 14 years ago by domlowe

  • Cc rkl lawrence removed
  • Description modified (diff)
  • Milestone changed from ALPHA to PreBeta

Renamed this to CSML v2 feature types as it's apparant that's what's needed. Also moved milestone to preBeta.

comment:8 Changed 14 years ago by domlowe

  • Status changed from assigned to closed
  • Resolution set to duplicate

Closing this

Note: See TracTickets for help on using tickets.