[eml-dev] spatialReference->horizCoordSysDef structure small change

[PeterMcCartney]

Just to give a little history, the entire structure of this section came
more or less verbatim from Esri's syntax for expressing projection
information their Arc products, and particularly in their .prj file
format. While you are technically correct in that a projected coordinate
system must reference a geographic coordinate system, and thus all
coordinate systems (except arbitrary ones) include a gegoCoordSys, im
not sure most users are concious of that. They just know its in utm zone
whatever and that this is interchangeable with some geographic
coordinate system to the extend that they both have northing and easting
axes. stating the geogcoordsys and then the project just sounds funny
the way Yoda speaks, although either order conveys the info you need. 

remember we only write the schema once, but we write thousands of xml
files. so the question is, does this really make an optimal improvement
in the xml, or is it just about making the schema more readable?


On Fri, 2005-11-18 at 15:19 -0700, Inigo San Gil wrote:
> Here is the thing, eml-dev:
> 
> This came across when revisiting a crosswalk between
> EML and FGDC.
> 
> The structure under the hierarchy tree:
> 
> <spatialReference>
>   <horizCoordSysDef>
> 
>   should be changed.
> 
> Currently, the user needs to make a choice under <horizCoordSysDef>.
> The options are <geogCoordSys> or <projCoordSys>.
> 
> However, if the user chooses to populate <projCoordSys> then
> is forced to populate a children element that is exactly the same as
> <geogCoordSys>. While this may make sense, we can restructure
> the tree, simplify it, and still meet the original requirements.
> 
> The way I see it, no matter what the uses needs to populate
> the element <geogCoordSys>. Then there is no place for a
> choice, but a sequence, where the element <projCoordSys>
> is optional.
> 
> So, from the Current EML tree:
> 
>                                               |----geogCoordSys
> horizCoordSysDef 
> ---/choice/--                                                    
> |----geogCoordSys
>                                               
> |----projCoordSys----/sequence/---
>                                               
>                                                      |----projection
> 
> We may want to go to this NEW EML tree:
> 
>                                                    |----geogCoordSys
> horizCoordSysDef ---/sequence/---
>                                                    |----projCoordSys 
> -----|--projection
> 
> 
> where the element <projCoordSys> in the NEW tree should now be optional
> to reflect well the "choice" given in the current EML version.
> (all these are mandatory in the current EML tree).
> 
> The key is that there is no "choice" to speak of  in the current tree,
> despite of what the schema suggests, no matter what branch you go, you have
> to populate <geogCoordSys>.
> 
> If I am missing something, please let me know, I am not a user of this
> EML section, nor I bumped into examples, or documents that have used
> this yet.
> 
> I dont think this should create problems with existing documents. They
> can be easily transformed, if any doc. is using these elements at all.
> 
> 
> Best, Inigo
> _______________________________________________
> Eml-dev mailing list
> Eml-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev