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

[Martin Davis]

I think #1 is the way to go.  And no, there currently is no code in
the parse to read the comments as descriptions.  There will be
substantial reworking required there.  I can think about how best to
do this if you like - I'm pretty comfortable with parsing files.

GUI ideas sound find to me.

M

On Fri, Feb 26, 2010 at 9:00 AM, Sunburned Surveyor
<sunburned.surveyor at gmail.com> wrote:
> Martin wrote: "So I don't think there's a need for a separate
> CRSIdentifier class -
> the current CRS class has everything needed."
>
> OK. I'll kill my CrsIdentifier class. Simplicity is better.
>
> It sounds like I need to get my lest of CrsIdentifiers from the CRS
> objects provided by the built-in parser. I'll go with that approach.
>
> However, I don't see a mechanism in the code to access the comments in
> the NAD files for each CoordinateSystem object. (I looked at the
> Proj4FileReader and the CoordinateSystemFactory class, but I might
> have missed something.) I think this means we have three (3) choices:
>
> (1) Add a method to the CoordinateSystem class to allow access the
> comments for each CoordinateSystem stored in the NAD files and tweak
> the parser to provide these comments.
>
> (2) Allow a separate method on the parser to provide the comments for
> a CoordinateSystem.
>
> (3) Ignore comments in the GUI for now.
>
> Martin wrote: "The views of this are
> where much work is needed - typically defining and presenting these
> kinds of views and search capabilities are much more work than the
> underlying model."
>
> I agree this is where most of the work will be. I don't think we want
> a list box with 2000 entries. I think I'll need to create an easier
> way to navigate and filter the list of available coordinate systems. I
> was going to use JGoodies Forms layout and Swing for my GUI.
>
> Do you have any objections to this?
>
> Landon
>
> On Thu, Feb 25, 2010 at 8:50 PM, Martin Davis <mtnclimb at gmail.com> wrote:
>> Landon,
>>
>> Re the the handling of CRS descriptions.  I see the parsing and model
>> of CRSes working like this:
>>
>> - the Proj4FileReader will read a given input file in "PROJ4 format"
>> into a list of CRS objects.
>> - a CRS object will have an authority code, an id within the authority
>> namespace, and a textual description.  (This is pretty much
>> implemented now)
>> - The UI can provide whatever views of that list (or lists - one for
>> each input file = authority) is required.  I can see a need for at
>> least a view which shows the Auth, ID, and Desc all together.  It
>> might be nice to be able to sort by ID or description - although it's
>> probably more useful to provide text search within descriptions
>>
>> So I don't think there's a need for a separate CRSIdentifier class -
>> the current CRS class has everything needed.  The views of this are
>> where much work is needed - typically defining and presenting these
>> kinds of views and search capabilities are much more work than the
>> underlying model.
>>
>> HTH...
>>
>>
>> On Wed, Feb 24, 2010 at 4:47 PM, Sunburned Surveyor
>> <sunburned.surveyor at gmail.com> wrote:
>>
>>> 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.
>>
>