[Proj4j] Question About Valid CRS Identifiers To Get Started With GUI Development

[Sunburned Surveyor]

 Martin wrote: "1) nad stands for North American Datum.  It's a bad
name for the CRS
catalogue file directoy, but that's what PROJ4 calls it."

That is what I thought.

Martin wrote: "We could always have a utility to
convert the PROJ4 format to the richer one."

I don't think we need to go that far yet. I was just looking for a way
to extract the CRS identifier information from the NAD files.

Martin wrote: "I think it's fine to work in trunk, as long as you
don't break the
build on commit, and as long as you communicate any changes needed to
the core API to support the GUI (so we can all agree that they make
sense for all use cases)"

I'm not seeing the need for any changes to the Proj4J core. But I
think I will work in the branch, just to be safe. We haven't worked
together very much and I don't want to be stepping on your toes.

Landon

On Thu, Feb 25, 2010 at 5:53 PM, Martin Davis <mtnclimb at gmail.com> wrote:
> 1) nad stands for North American Datum.  It's a bad name for the CRS
> catalogue file directoy, but that's what PROJ4 calls it.
>
> 2) The # sign is the comment indicator for the CRS files.  So we'll
> have to use some heuristics to determine which comments actually carry
> CRS descriptions.  It's mostly consistent, so I don't think this will
> be too bad.
>
> I don't want to change the CRS files, or how they are defined, since
> they are directly copied from PROJ4, and would be a pain to keep up to
> date.
>
> <wild-and-craziness>
> But it would be fair to define our own better CRS file format and use
> that as an alternate, I suppose.  XML might be overkill for this -
> perhaps a simple XML-Lite format?  Something like:
>
> <Code>1234
> <Description>blah blah
> <Definition>+proj=foobar etc
>
> That's easy to parse and work with.  We could always have a utility to
> convert the PROJ4 format to the richer one.
>
> 2a) Yes the PROJ4 File Reader is a bit of a hack right now.  It can be
> replaced with something better.  Ideally there will only be one
> reader, however.  If the reader gets the capability to read the CRS
> description as well, it will be nice to make this available in the CRS
> objects defined.
>
> 2b) Not sure about getFormalCRSIdentifierForFriendlyCRSIdentifier -
> will think about this more
>
> 2c) I think it's fine to work in trunk, as long as you don't break the
> build on commit, and as long as you communicate any changes needed to
> the core API to support the GUI (so we can all agree that they make
> sense for all use cases)
>
> M
>
>
> On Wed, Feb 24, 2010 at 4:47 PM, Sunburned Surveyor
> <sunburned.surveyor at gmail.com> wrote:
>> Martin,
>>
>> I'm finally getting some time after work today to look at the GUI
>> design issues we discussed a little closer. I have some more questions
>> that I was hoping you could help me with.
>>
>> Martin wrote: "CRS IDs - the PROJ4 archive of CRSes is in the /nad directory, in
>> various files called "epsg", "esri", etc."
>>
>> (1) What does "nad" stand for? Does the current proj4j library support
>> all 5 different CRS definition formats (epsd, esri, nad27, nad83,
>> world)?
>>
>> Martin wrote: "I'm taking the file name as
>> the Authority code.  Each file contains comments, and CRS definitions
>> which look like:
>>
>> <id> proj4 spec string
>>
>> So createFromName takes a CRS name which looks like eg "EPSG:1234" and
>> looks up that CRS in the EPSG file.  (I will add all this to the
>> javadoc...)"
>>
>> Martin also wrote: "One thing that would be VERY nice is to be able to
>> capture the CRS
>> descriptions which are typically in the comment immediately before the
>> CRS spec.  This should be a fairly simply amendment to the parser."
>>
>> (2) I noticed the epsg file (as an example) has two elements for each
>> CRS that could potentially be used to identify the CRS to the user.
>> The first is the integer code. The second is a more user friendly name
>> included as the comment. I think I will need to display both in the
>> list box to make the GUI useful to the user. Is the number sign used
>> to mark other types of comments in the NAD files, or just these user
>> friendly CRS identifiers? I want to make sure I can depend on the user
>> friendly CRS identifier following immediately after the number sign.
>> (Or we could add a tag after the number sign for those user friendly
>> identifiers so I will know when I find them.)
>>
>> Martin wrote: "Now, the current file parser just extracts a single CRS
>> from the file.
>>  It does parse the entire file tho, so could easily be extended to
>> extract all of them."
>>
>> When you say "current file parser" do you mean the Proj4FileReader
>> class? I took a look at the source code for that class today. The
>> readFile method looks pretty scary. Do you want me to add the
>> functionality I need to extract CRS identifiers from the NAD files to
>> that class or to a different class? I'm thinking of two methods like:
>>
>> public List<String> getFormalCRSIdentifiers()
>> public List<String> getFriendlyCRSIdentifiers()
>>
>> I can also see a need for two methods like:
>>
>> public String getFormalCRSIdentifierForFriendlyCRSIdentifier()
>> public String getFriendlyCRSIdentifierForFormalCRSIdentifier()
>>
>> But those could be put into a utility class. Do you want to package
>> the authority code, formal identifier, and friendly identifier in its
>> own CrsIdentifier class, or is that getting two complicated? We could
>> start using the CrsIdentifier class in the GUI and then use it later
>> in the rest of the library if desired.
>>
>> I've got some things I can start on while I wait for these answers.
>> I'm going to create a new package named org.osgeo.proj4j.gui. I won't
>> commit this until I get your permission. Do you want me working on my
>> GUI stuff in the trunk of the SVN or in a new branch?
>>
>> Thanks,
>>
>> Landon
>>
>> On Mon, Feb 8, 2010 at 8:56 AM, Martin Davis <mtnclimb at gmail.com> wrote:
>>> Landon,
>>>
>>> Your note contains lots of subthreads!  Here goes with my thoughts:
>>>
>>> * CRS IDs - the PROJ4 archive of CRSes is in the /nad directory, in
>>> various files called "epsg", "esri", etc.  I'm taking the file name as
>>> the Authority code.  Each file contains comments, and CRS definitions
>>> which look like:
>>>
>>> <id> proj4 spec string
>>>
>>> So createFromName takes a CRS name which looks like eg "EPSG:1234" and
>>> looks up that CRS in the EPSG file.  (I will add all this to the
>>> javadoc...)
>>>
>>> Now, the current file parser just extracts a single CRS from the file.
>>>  It does parse the entire file tho, so could easily be extended to
>>> extract all of them.
>>>
>>> One thing that would be VERY nice is to be able to capture the CRS
>>> descriptions which are typically in the comment immediately before the
>>> CRS spec.  This should be a fairly simply amendment to the parser.
>>>
>>> * I agree with your proposed design for the UI - that's pretty much
>>> what I was thinking too.  Shapefile support would be great, and it
>>> makes sense to use the GeoTools code.  I was also thinking of
>>> providing a text box to allow a user to directly enter a coordinate,
>>> too.
>>>
>>> * The MetaCRS test parser is pretty much done.  Have a look at
>>> MetaCRSTestCmd. java.
>>>
>>> * One thing that would be nifty is if the GUI would also accept a
>>> MetaCRS test file, and run all the tests in it.  Something like the
>>> JUnit runner in Eclipse.  A nice display of all tests and their status
>>> would be great.
>>>
>>> This could even turn into a full-blown MetaCRS test file editor...  !
>>> That wouild be a great tool to promote the concept.
>>>
>>> * I'm still keen on reviving Jerry's great visual display of
>>> coordinate projections on a world map.  I did ask for the code, but
>>> haven't got anything so far.  Shouldn't be too hard to reproduce it
>>> though.
>>>
>>> Martin
>>>
>>>
>>> On Fri, Feb 5, 2010 at 4:05 PM, Sunburned Surveyor
>>> <sunburned.surveyor at gmail.com> wrote:
>>>> Martin,
>>>>
>>>> I was looking over the example code you sent me a few weeks ago. This
>>>> led me to a question that I want to ask about Proj4J. The answers will
>>>> help me get started with the GUI development.
>>>>
>>>> I see that we pass the CoordinateSystemFactory.createFromName method
>>>> some type of identifier to obtain a coordinate system. Is there a
>>>> mechanism within Proj4J that I can use to obtain a list of valid
>>>> identifiers? I know this information may be embedded in some text
>>>> files or configuration files. That is fine. I can write a parser if
>>>> needed to obtain the list if you can point me in the correct place to
>>>> look. I want to present the user with a list box of valid CRS
>>>> identifiers. (Actually, I will need two (2) list boxes. One will be
>>>> for the source CRS and one will be for the desination CRS.)
>>>>
>>>> Once I get this figured out, I think the rest will come together
>>>> without too much of your help. I think I will need to build some
>>>> wrapper layers that extract ProjCoordinate objects from feature
>>>> geometries stored in a Shapefile. I imagine transformation of
>>>> Shapefiles will be our typical use case. Of course, people could want
>>>> to transform spatial data from other sources too, but I want to get
>>>> something working with Shapefiles first.
>>>>
>>>> So it looks like I will have to layers to implement. One will be the
>>>> actual GUI, the second will be a layer that reads and writes
>>>> ProjCoordinate objects from feature geometries in different formats,
>>>> like ESRI shapefiles. I'm thinking I will tap the GeoTools library for
>>>> Shapefile support at this point.
>>>>
>>>> Let me know what your thoughts are on this.
>>>>
>>>> It may take me a few weeks to get a working GUI for Shapefile
>>>> conversion. After this is done I will work on the parser for the
>>>> MetaCRS test data.
>>>>
>>>> The Sunburned Surveyor
>>>> _______________________________________________
>>>> Proj4j mailing list
>>>> Proj4j at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/proj4j
>>>>
>>>
>>
>