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

[Sunburned Surveyor]

Martin wrote: "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."

Its up to you. I'm pretty comfortable writing parsers too. You might
be more familiar with the Proj parser though. I can start work on the
GUI with the understanding that option #1 will be implemented at some
point in the future. Just let me know.

Martin wrote: "GUI ideas sound find to me."

OK. I'm out of town until Thursday of next week. But I will see what I
can do on the GUI when I get back.

Landon

On Fri, Feb 26, 2010 at 9:04 AM, Martin Davis <mtnclimb at gmail.com> wrote:
> 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.
>>>
>>
>