From: Emin Hasanov <emin@ha...>  20050404 20:16:42

I have got several raster maps that are projected using MGRS. Is this supported by Geotools? I wasn't able to find any information on this... I know MGRS is based on UTM, but am not sure how to apply this to get proper projection. Thanks, Emin 
From: Martin Desruisseaux <martin.desruisseaux@no...>  20050404 22:15:02

Emin Hasanov a =E9crit : > I have got several raster maps that are projected using MGRS. Is this=20 > supported by Geotools? I wasn't able to find any information on this... >=20 > I know MGRS is based on UTM, but am not sure how to apply this to get=20 > proper projection. I'm not familiar to MGRS. If this is UTM formulas, and if the "MGRS"=20 name simply stand for wellknow parameters (e.g. semiaxis length), then=20 you should be able to uses Geotools. But you will need to know the=20 projection parameters. I guess they are published somewhere? Martin. 
From: Emin Hasanov <emin@ha...>  20050404 22:21:28

Martin, MGRS stands for Military Grid Reference System (MGRS) and is an extension to UTM further splitting the map by 100km squares. As far as I can understand from http://www.fmnh.helsinki.fi/english/botany/afe/map/utm.htm this is not simply different parameters for projection, but different way of calculation... Thanks, Emin Martin Desruisseaux wrote: > Emin Hasanov a écrit : > >> I have got several raster maps that are projected using MGRS. Is this >> supported by Geotools? I wasn't able to find any information on this... >> >> I know MGRS is based on UTM, but am not sure how to apply this to get >> proper projection. > > > I'm not familiar to MGRS. If this is UTM formulas, and if the "MGRS" > name simply stand for wellknow parameters (e.g. semiaxis length), > then you should be able to uses Geotools. But you will need to know > the projection parameters. I guess they are published somewhere? > > Martin. 
From: Martin Desruisseaux <martin.desruisseaux@no...>  20050404 23:22:47

Emin Hasanov a =E9crit : > As far as I can understand from=20 > http://www.fmnh.helsinki.fi/english/botany/afe/map/utm.htm this is not=20 > simply different parameters for projection, but different way of=20 > calculation... There is no direct MGRS supports in Geotools as far as I know, but=20 contributions are always welcome :). If the formulas are different, we need to write a new implementation of=20 MapProjection for this case. But I'm not sure that the formulas are=20 really different. My understanding of the above cited link is that MGRS=20 provided a sophesticated way to divides the earth in different zones, to=20 identifies those zones by some alphanumeric codes, and to infer UTM=20 parameters from those codes. If this is true, then we don't really need=20 a MapProjection implementation. A MapProjection.Provider implementation=20 would be suffisient. Martin. 
From: Rueben Schulz <r_j_schulz@ya...>  20050405 05:57:50

>From my understanding of the link, MGRS is just a really complicated method of assigning a map grid code to a UTM coordinate (which agrees with Martin's interpretation). Hopefully the referenced DMA document provides more information. This is not a traditional projection (forward and inverse functions that return numbers), so I am not sure how it should be implemented. For now someone (not me) could just write a utility function that takes a utm coordinate and computes the alphanumeric mgrs code (and does the inverse to some level of precision). One place where this could be done is the TransverseMercator class where there is already some old utility functions to calculate utm zones from longitude. As Martin said, contributions are always welcome. Rueben On Tue, 20050504 at 10:22 +1100, Martin Desruisseaux wrote: > Emin Hasanov a écrit : > > As far as I can understand from > > http://www.fmnh.helsinki.fi/english/botany/afe/map/utm.htm this is not > > simply different parameters for projection, but different way of > > calculation... > > There is no direct MGRS supports in Geotools as far as I know, but > contributions are always welcome :). > > If the formulas are different, we need to write a new implementation of > MapProjection for this case. But I'm not sure that the formulas are > really different. My understanding of the above cited link is that MGRS > provided a sophesticated way to divides the earth in different zones, to > identifies those zones by some alphanumeric codes, and to infer UTM > parameters from those codes. If this is true, then we don't really need > a MapProjection implementation. A MapProjection.Provider implementation > would be suffisient. > > Martin. > > >  > SF email is sponsored by  The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_ide95&alloc_id396&op=click > _______________________________________________ > Geotoolsgt2users mailing list > Geotoolsgt2users@... > https://lists.sourceforge.net/lists/listinfo/geotoolsgt2users 
From: Emin Hasanov <emin@ha...>  20050405 07:57:10

Rueben, Martin, Looks like I will need to dig further to see how I can extend TransverseMercator class to use this projection. I will definitely contribute should I manage to do this :) On a separate, but linked matter, just wanted to have your advice to better understand the process. My map is spread over 4 different zones (38T, 39T, 38S, 39S), but my understanding is that I can only georeference 2 corners of the raster and use one single projection for the whole map. However, when I convert lat/long to meters they do not grow linearly, but are reset to smaller values once you cross border between zones. Hence I am not sure how to project this properly. Is there a way to calibrate raster using approach similar to the programs like OziExplorer? One need to choose several points on the map and identify their lat/long values and OziExplorer automatically identifies everything else for you. Thanks, Emin >>From my understanding of the link, MGRS is just a really complicated > method of assigning a map grid code to a UTM coordinate (which agrees > with Martin's interpretation). Hopefully the referenced DMA document > provides more information. > > This is not a traditional projection (forward and inverse functions that > return numbers), so I am not sure how it should be implemented. For now > someone (not me) could just write a utility function that takes a utm > coordinate and computes the alphanumeric mgrs code (and does the inverse > to some level of precision). One place where this could be done is the > TransverseMercator class where there is already some old utility > functions to calculate utm zones from longitude. > > As Martin said, contributions are always welcome. > Rueben > > > On Tue, 20050504 at 10:22 +1100, Martin Desruisseaux wrote: >> Emin Hasanov a écrit : >> > As far as I can understand from >> > http://www.fmnh.helsinki.fi/english/botany/afe/map/utm.htm this is not >> > simply different parameters for projection, but different way of >> > calculation... >> >> There is no direct MGRS supports in Geotools as far as I know, but >> contributions are always welcome :). >> >> If the formulas are different, we need to write a new implementation of >> MapProjection for this case. But I'm not sure that the formulas are >> really different. My understanding of the above cited link is that MGRS >> provided a sophesticated way to divides the earth in different zones, to >> identifies those zones by some alphanumeric codes, and to infer UTM >> parameters from those codes. If this is true, then we don't really need >> a MapProjection implementation. A MapProjection.Provider implementation >> would be suffisient. >> >> Martin. >> >> >>  >> SF email is sponsored by  The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_ide95&alloc_id396&op=click >> _______________________________________________ >> Geotoolsgt2users mailing list >> Geotoolsgt2users@... >> https://lists.sourceforge.net/lists/listinfo/geotoolsgt2users > > 
From: Martin Desruisseaux <martin.desruisseaux@no...>  20050405 09:09:30

Emin Hasanov a =E9crit : > My map is spread over 4 different zones > (38T, 39T, 38S, 39S), but my understanding is that I can only georefere= nce > 2 corners of the raster and use one single projection for the whole map. This is the default way. But if you want more sophesticated mapping, you=20 can. There is 2 variants of GridCoverage2D constructors: GridCoverage2D(..., CoordinateReferenceSystem, Envelope, ...) (this is the easiest way), and: GridCoverage2D(..., CoordinateReferenceSystem, MathTransform, ...) The second case gives you more freedom. But you have to setup (again)=20 yours own MathTransform implementation, which would be a composition of=20 4 AffineTransforms in adjacent tiles. > However, when I convert lat/long to meters they do not grow linearly, b= ut > are reset to smaller values once you cross border between zones. Hence = I > am not sure how to project this properly. See above. A custom MathTransform implementation could do the work. We=20 could provide a standard class in Geotools for that, but it is not yet do= ne. > Is there a way to calibrate raster using approach similar to the progra= ms > like OziExplorer? One need to choose several points on the map and > identify their lat/long values and OziExplorer automatically identifies > everything else for you. It depends what you means by identifying everything else for you. You=20 may use polynomial warping. You may use Delaunay triangulation. There is=20 a variety of technics. We implemented Delaunay triangulation in ours own=20 laboratory, but this code is not yet on Geotools (it may move there later= ). Martin. 
From: Rueben Schulz <r_j_schulz@ya...>  20050406 06:13:58

On Tue, 20050504 at 12:57 +0500, Emin Hasanov wrote: > Rueben, Martin, > > On a separate, but linked matter, just wanted to have your advice to > better understand the process. My map is spread over 4 different zones > (38T, 39T, 38S, 39S), but my understanding is that I can only georeference > 2 corners of the raster and use one single projection for the whole map. Usually single maps only use one projection. In your case the 38 (T and S) and 39 (T and S) mapsheets are in two different UTM zones (with different central meridians). Generally when showing data from two utm zones you need to project them both to the same projection or one mapsheet to the utm projection of another zone (not good if your maps cross many utm zone boundaries). Rueben 