Re: [GRASS-user] Latitude/Longitude vs UTM
Glynn wrote: > The SW fragment of NH which is in zone 18 is only around half a > degree; projecting that into zone 19 isn't really an issue. > Or you could just use a custom transverse Mercator projection > with the central meridian at e.g. 71d30'W. ... and of course there will be a state plane projection designed for each state already, for NH they use 71d45'W. EPSG code(s): # NAD83(HARN) / New Hampshire <2823> +proj=tmerc +lat_0=42.5 +lon_0=-71.67 +k=0.7 +x_0=30 +y_0=0 +ellps=GRS80 +units=m +no_defs <> # NAD83(NSRS2007) / New Hampshire <3613> +proj=tmerc +lat_0=42.5 +lon_0=-71.67 +k=0.7 +x_0=30 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs <> # NAD83 / New Hampshire <32110> +proj=tmerc +lat_0=42.5 +lon_0=-71.67 +k=0.7 +x_0=30 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m +no_defs <> ... and several more US survey ft variants. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: grass-user Digest, Vol 49, Issue 27
Is projecting to NH state plane and option? Along the lines of using something more localized. Mark On May 14, 2010, at 2:06 PM, Kurt Springs wrote: Thanks Rich and Dylan I downloaded the pdf of document #1395. At the moment I am leaning toward Lambert Conic Conformal (1SP) since it seems to use Lat/Long of Natural Origin, in case I need to use a GPS. If I am reading you right Latitude and longitude don't even come into the equation, just the projection. I've been looking at the website http://www.dmap.co.uk/ utmworld.htm. I was mistaken it was 18 and 19T that NH falls in. However, it appears to be just the western most sliver. However, if I don't have to figure out the conversion, so much the better. Kurt On May 14, 2010, at 12:00 PM, grass-user-requ...@lists.osgeo.org wrote: Message: 2 Date: Fri, 14 May 2010 08:10:20 -0700 From: Dylan Beaudette Subject: Re: [GRASS-user] Latitude/Longitude vs UTM To: Rich Shepard Cc: GRASS user list Message-ID: Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 14, 2010 at 6:22 AM, Rich Shepard > wrote: On Thu, 13 May 2010, Kurt Springs wrote: This was interesting in that it told me that r.topidx could not be run with latitude and longitude and I had to convert to UTM. I was wondering if this is the answer to the problem and I just had to convert to UTM. Kurt, Lat/Long represents geographic coordinates, not a projection of location on a mathematial model of the earth. UTM is the Universal Transverse Mercador projection that we see on most printed (or computer displayed) maps of the earth. There is documentation within the GRASS Web site that provides a good explanation of the differences. GRASS modules work on geographic projections, not just coordinates. There is a USGS technical report from the mid-1980s that's the standard on projections. While it is becoming more rare to locatate, see if you can find a copy. I think that Rich is referring to this USGS document, #1395 http://pubs.er.usgs.gov/usgspubs/pp/pp1395 Definitely worth the price if you want to become an expert in map projections. One other question. New Hampshire appears to fall within two UTM zones (19T and 20T) Is there a way for a maps set to contain two UTM zones? Yes. Don't use UTM. In this case use a regional projection that suits your needs: 1) navigation --> use a conformal projection 2) area statistics --> use an equal-area projection ... etc ... Variations on the Albers or Lambert (conformal) conic projections work quite well for large regions that are wider than tall, but for such as small state should be just fine. We use an Albers equal-area projection to house soil survey data for the lower 48 states. Interesting. NH is a tall, narrow state so one would assume it would be within a single zone. Regardless, yes there is a way to reproject locations in one zone on the other, but it's non trivial and I've not done it. I wouldn't recommend it. The desirable properties of the UTM system (i.e. the fairly good compromise between distortion, preservation of angles, and preservation of area) only occur within a zone's boundaries. The farther you move from the central meridian of the UTM zone, the more distortion you will encounter-- therefore 'projecting' UTM z10 data into UTM z11 is technically possible, but not a great idea. Oregon is primarily in Zone 10, but the eastern edge (I don't recall the distance within the state) is in Zone 11. The available DEM and hydrologic data were reprojected from 11 to 10 by the supplying agency. Hmm... Dylan Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Latitude/Longitude vs UTM
For the record: not only norway has compensation zones in the UTM grid (so to stay in just one fuse) but also here in italy we have some regions (LAU2 units) that span across 32 and 33 and project all on 32. As far as you don't exceed 2/300 km, IMHO you can extend into the adjacent fuse... HTH -- Damiano G. Preatoni UAGRA-DASS Università dell'Insubria Via J.H. Dunant, 3 I 21100 Varese [via mobile] -original message- Subject: Re: [GRASS-user] Latitude/Longitude vs UTM From: Glynn Clements Date: 2010-05-14 20:28 Dylan Beaudette wrote: > > There is a USGS technical report from the mid-1980s that's the standard on > > projections. While it is becoming more rare to locatate, see if you can find > > a copy. > > I think that Rich is referring to this USGS document, #1395 > > http://pubs.er.usgs.gov/usgspubs/pp/pp1395 > > Definitely worth the price if you want to become an expert in map projections. According to that page, it's no longer available in hardcopy; however, you can download it as a PDF. > > Interesting. NH is a tall, narrow state so one would assume it would be > > within a single zone. Regardless, yes there is a way to reproject locations > > in one zone on the other, but it's non trivial and I've not done it. > > I wouldn't recommend it. The desirable properties of the UTM system > (i.e. the fairly good compromise between distortion, preservation of > angles, and preservation of area) only occur within a zone's > boundaries. The farther you move from the central meridian of the UTM > zone, the more distortion you will encounter-- therefore 'projecting' > UTM z10 data into UTM z11 is technically possible, but not a great > idea. That doesn't stop Norway doing it ;) http://upload.wikimedia.org/wikipedia/commons/e/ed/Utm-zones.jpg See 32V and 31X/33X/35X/37X. The SW fragment of NH which is in zone 18 is only around half a degree; projecting that into zone 19 isn't really an issue. Or you could just use a custom transverse Mercator projection with the central meridian at e.g. 71d30'W. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Latitude/Longitude vs UTM
On Fri, May 14, 2010 at 5:05 AM, Kurt Springs wrote: > Hi Folks, > > I have been playing with the seamless maps from the USGS. Specifically, my > question is on the effect of Latitude/Longitude vs UTM with respect to > hydrology modules such as r.watershed and r.topidx. I was trying to generate > watershed maps with r.watershed. I've done this before for my dissertation. > They did not turn out the same. Are the region settings the same? Is the resolution of the new DEM identical to the old DEM? Resolution and extend must be identical if you want to compare results. > They looked strange compared to what I generated before. In what way? > Moreover, they maps kept falling in the same place in the map set regardless > of what I turned off or on. (i.e. some where in the center top, when the > map was generated from a dem on the bottom.) Was the computational region set to the resolution and extends of the dem on the bottom? The current computational region influences heavily the results of any raster map processing. If current extend and resolution are not properly set, the results may be astonishing. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Latitude/Longitude vs UTM
Dylan Beaudette wrote: > > There is a USGS technical report from the mid-1980s that's the standard on > > projections. While it is becoming more rare to locatate, see if you can find > > a copy. > > I think that Rich is referring to this USGS document, #1395 > > http://pubs.er.usgs.gov/usgspubs/pp/pp1395 > > Definitely worth the price if you want to become an expert in map projections. According to that page, it's no longer available in hardcopy; however, you can download it as a PDF. > > Interesting. NH is a tall, narrow state so one would assume it would be > > within a single zone. Regardless, yes there is a way to reproject locations > > in one zone on the other, but it's non trivial and I've not done it. > > I wouldn't recommend it. The desirable properties of the UTM system > (i.e. the fairly good compromise between distortion, preservation of > angles, and preservation of area) only occur within a zone's > boundaries. The farther you move from the central meridian of the UTM > zone, the more distortion you will encounter-- therefore 'projecting' > UTM z10 data into UTM z11 is technically possible, but not a great > idea. That doesn't stop Norway doing it ;) http://upload.wikimedia.org/wikipedia/commons/e/ed/Utm-zones.jpg See 32V and 31X/33X/35X/37X. The SW fragment of NH which is in zone 18 is only around half a degree; projecting that into zone 19 isn't really an issue. Or you could just use a custom transverse Mercator projection with the central meridian at e.g. 71d30'W. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: grass-user Digest, Vol 49, Issue 27
Thanks Rich and Dylan I downloaded the pdf of document #1395. At the moment I am leaning toward Lambert Conic Conformal (1SP) since it seems to use Lat/Long of Natural Origin, in case I need to use a GPS. If I am reading you right Latitude and longitude don't even come into the equation, just the projection. I've been looking at the website http://www.dmap.co.uk/utmworld.htm. I was mistaken it was 18 and 19T that NH falls in. However, it appears to be just the western most sliver. However, if I don't have to figure out the conversion, so much the better. Kurt On May 14, 2010, at 12:00 PM, grass-user-requ...@lists.osgeo.org wrote: > > Message: 2 > Date: Fri, 14 May 2010 08:10:20 -0700 > From: Dylan Beaudette > Subject: Re: [GRASS-user] Latitude/Longitude vs UTM > To: Rich Shepard > Cc: GRASS user list > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > On Fri, May 14, 2010 at 6:22 AM, Rich Shepard > wrote: >> On Thu, 13 May 2010, Kurt Springs wrote: >> >>> This was interesting in that it told me that r.topidx could not be run >>> with latitude and longitude and I had to convert to UTM. I was wondering >>> if this is the answer to the problem and I just had to convert to UTM. >> >> Kurt, >> >> Lat/Long represents geographic coordinates, not a projection of location >> on a mathematial model of the earth. UTM is the Universal Transverse >> Mercador projection that we see on most printed (or computer displayed) maps >> of the earth. There is documentation within the GRASS Web site that provides >> a good explanation of the differences. GRASS modules work on geographic >> projections, not just coordinates. >> >> There is a USGS technical report from the mid-1980s that's the standard on >> projections. While it is becoming more rare to locatate, see if you can find >> a copy. > > I think that Rich is referring to this USGS document, #1395 > > http://pubs.er.usgs.gov/usgspubs/pp/pp1395 > > Definitely worth the price if you want to become an expert in map projections. > > >>> One other question. New Hampshire appears to fall within two UTM zones >>> (19T and 20T) Is there a way for a maps set to contain two UTM zones? > > Yes. Don't use UTM. In this case use a regional projection that suits > your needs: > > 1) navigation --> use a conformal projection > 2) area statistics --> use an equal-area projection > ... etc ... > > Variations on the Albers or Lambert (conformal) conic projections work > quite well for large regions that are wider than tall, but for such as > small state should be just fine. We use an Albers equal-area > projection to house soil survey data for the lower 48 states. > >> Interesting. NH is a tall, narrow state so one would assume it would be >> within a single zone. Regardless, yes there is a way to reproject locations >> in one zone on the other, but it's non trivial and I've not done it. > > I wouldn't recommend it. The desirable properties of the UTM system > (i.e. the fairly good compromise between distortion, preservation of > angles, and preservation of area) only occur within a zone's > boundaries. The farther you move from the central meridian of the UTM > zone, the more distortion you will encounter-- therefore 'projecting' > UTM z10 data into UTM z11 is technically possible, but not a great > idea. > >> Oregon is primarily in Zone 10, but the eastern edge (I don't recall the >> distance within the state) is in Zone 11. The available DEM and hydrologic >> data were reprojected from 11 to 10 by the supplying agency. > > Hmm... > > Dylan > >> Rich >> ___ >> grass-user mailing list >> grass-user@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Copying from a mapset in another data directory
Jonathan Greenberg wrote: > I have some rasters in a grass data directory on a different mounted > drive in unix that i want to copy into a different data directory + > mapset -- i can't seem to figure out how to do this with g.copy, which > AFAIK only copies from mapsets within a given data directory. Indeed, g.copy only works on maps within the same location. For good reason: maps in different locations typically have different projections, so you can't simply copy the data. The only supported ways of "copying" a map in a different location are: 1. Use r.proj or v.proj, which will re-project the data based upon the projections of the source location and the current location. 2. Use e.g. r.out.gdal/v.out.ogr to export the data and r.in.gdal/v.in.ogr to re-import it. The latter will check that the projection is correct. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] dems from coordinate lists
Hi Micha, I tried your suggestion after setting the region to 20m instead of the raster DEM's 25m.: v.surf.rst input="dem_2628cc_...@c83" layer=0 elev="dem_2628cc_rst_elev" tension=40. segmax=40 npmin=120 dmin=9.998022 dmax=49.990111 zm ult=1.0 This worked, but the differences between the raster DEM that I created with r.in.xyz and the rst interpolated results are quite big - ranging from -6.882202m to +7.864258m. It also ran fairly slowly. Without adjusting the npmin paramter from the default (300) to 120 it literally ran for hours (Win XP, 3GHz CPU, 1GB RAM). Adjusting npmin to 120 didn't seem to affect the error range of the outcome much. Is there a reason why I should use r.surf.rst instead of v.surf.rst? Or perhaps I should just import the points with r.in.xyz and leave the DEM in this format for further applications (hydrological modelling)? Regards Hanlie 2010/5/13, Micha Silver : > MS wrote: > >> If I follow correctly, instead of v.to.rast, you need to interpolate a >> raster DEM from the points. v.surf.rst produces nice results, but >> there are other interpolation modules as well in the raster category. >> > That's the method I use also. > I start with: > v.in.ascii -z in= z=3 out=vect_pts > This creates a 3D vector using the z column as the height values. > Now set the desired region: > g.region vect=vect_pts res=xxx > Choose the raster resolution that suits your needs. If the points in the > ascii file are at 25 m spacing, then you probably could interpolate at > 10m-20m resolution (or better) with no problems. > Then: > v.surf.rst in=vect_pts layer=0 elev=dem ... > The layer=0 parameter indicates that you're using the 3D vector's z > value for elevation. > -- > Micha ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Latitude/Longitude vs UTM
On Fri, May 14, 2010 at 6:22 AM, Rich Shepard wrote: > On Thu, 13 May 2010, Kurt Springs wrote: > >> This was interesting in that it told me that r.topidx could not be run >> with latitude and longitude and I had to convert to UTM. I was wondering >> if this is the answer to the problem and I just had to convert to UTM. > > Kurt, > > Lat/Long represents geographic coordinates, not a projection of location > on a mathematial model of the earth. UTM is the Universal Transverse > Mercador projection that we see on most printed (or computer displayed) maps > of the earth. There is documentation within the GRASS Web site that provides > a good explanation of the differences. GRASS modules work on geographic > projections, not just coordinates. > > There is a USGS technical report from the mid-1980s that's the standard on > projections. While it is becoming more rare to locatate, see if you can find > a copy. I think that Rich is referring to this USGS document, #1395 http://pubs.er.usgs.gov/usgspubs/pp/pp1395 Definitely worth the price if you want to become an expert in map projections. >> One other question. New Hampshire appears to fall within two UTM zones >> (19T and 20T) Is there a way for a maps set to contain two UTM zones? Yes. Don't use UTM. In this case use a regional projection that suits your needs: 1) navigation --> use a conformal projection 2) area statistics --> use an equal-area projection ... etc ... Variations on the Albers or Lambert (conformal) conic projections work quite well for large regions that are wider than tall, but for such as small state should be just fine. We use an Albers equal-area projection to house soil survey data for the lower 48 states. > Interesting. NH is a tall, narrow state so one would assume it would be > within a single zone. Regardless, yes there is a way to reproject locations > in one zone on the other, but it's non trivial and I've not done it. I wouldn't recommend it. The desirable properties of the UTM system (i.e. the fairly good compromise between distortion, preservation of angles, and preservation of area) only occur within a zone's boundaries. The farther you move from the central meridian of the UTM zone, the more distortion you will encounter-- therefore 'projecting' UTM z10 data into UTM z11 is technically possible, but not a great idea. > Oregon is primarily in Zone 10, but the eastern edge (I don't recall the > distance within the state) is in Zone 11. The available DEM and hydrologic > data were reprojected from 11 to 10 by the supplying agency. Hmm... Dylan > Rich > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Latitude/Longitude vs UTM
On Thu, 13 May 2010, Kurt Springs wrote: This was interesting in that it told me that r.topidx could not be run with latitude and longitude and I had to convert to UTM. I was wondering if this is the answer to the problem and I just had to convert to UTM. Kurt, Lat/Long represents geographic coordinates, not a projection of location on a mathematial model of the earth. UTM is the Universal Transverse Mercador projection that we see on most printed (or computer displayed) maps of the earth. There is documentation within the GRASS Web site that provides a good explanation of the differences. GRASS modules work on geographic projections, not just coordinates. There is a USGS technical report from the mid-1980s that's the standard on projections. While it is becoming more rare to locatate, see if you can find a copy. One other question. New Hampshire appears to fall within two UTM zones (19T and 20T) Is there a way for a maps set to contain two UTM zones? Interesting. NH is a tall, narrow state so one would assume it would be within a single zone. Regardless, yes there is a way to reproject locations in one zone on the other, but it's non trivial and I've not done it. Oregon is primarily in Zone 10, but the eastern edge (I don't recall the distance within the state) is in Zone 11. The available DEM and hydrologic data were reprojected from 11 to 10 by the supplying agency. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass user
2010/5/14 subbu sravan : > > Can any body help me to classify an image in GRASS 6.4.0 > If you send an Video, I will be very thankful to you http://grass.osgeo.org/wiki/Image_classification Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] grass user
Can any body help me to classify an image in GRASS 6.4.0 If you send an Video, I will be very thankful to you ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: dems from coordinate lists
Hi Jamie, Thanks, this worked perfectly. Regards Hanlie 2010/5/13, Jamie Adams : > Did you adjust the region also? To do this properly, you need to first scan > the file using r.in.xyz to get the extents. I'd also use the shell style > output. > > r.in.xyz -sg input="2628cc.ORT.xyz" output="dem_2628cc_25m_xyz > > Should return something like: > > n=1000 s=500 w=500 e=1000 t=### b=### > (you can ignore the t & b output) > > This is the extent of the points, which are going to be the center of the > output pixels. Since the region is defined as pixel edge, you need to > expand the region 1/2 a pixel in each direction to ensure the points are in > the center of the pixel. At 25m spacing, your region should be set as: > > g.region n=1012.5 s=487.5 w=487.5 e=1012.5 res=25 > > - Jamie > > On Thu, May 13, 2010 at 9:02 AM, Hanlie Pretorius < > hanlie.pretor...@gmail.com> wrote: > >> Hi Jamie, >> >> I tried r.in.xyz: >> (r.in.xyz input="2628cc.ORT.xyz" output="dem_2628cc_25m_xyz" >> method="mean" type="FCELL" x=1 y=2 z=3 zscale=1.0 percent=100) >> >> but I still get the rows of no data in the result. >> >> Hanlie >> >> >> > >> > You want the points to represent cell centers so you need to expand your >> > region 1/2 pixel in all four directions. Also look at using r.in.xyz, >> > it >> > works directly on this type of data. >> > >> > Jamie >> > >> > On Thu, May 13, 2010 at 7:26 AM, Hanlie Pretorius < >> > hanlie.pretor...@gmail.com> wrote: >> > >> >> Hi, >> >> >> >> I've obtained DEMs in text files with columns X, Y and Z at 25m >> >> spacing. The first three entries in the text file are: >> >> >> >> - >> >> X,Y,Z >> >> 99550,2.9883e+06,1473.47 >> >> 99550,2.98828e+06,1473.57 >> >> 99550,2.98825e+06,1473.63 >> >> - >> >> >> >> To me it seems the easiest way to import these is the following: >> >> >> >> 1. v.in.ascii >> >> >> >> 2. Set the region to the extents of new vector file and the resolution >> to >> >> 25m. >> >> >> >> 3. v.to.rast. >> >> >> >> >> >> This 'works' but I get horizontal strips of no data in my raster DEM >> >> at 25m spacings. >> >> >> >> Also, when I look at the raster and the vector layer together, the >> >> vector points are not always on the edges of the raster cells. >> >> >> >> Can someone perhaps help me to fix this? >> >> >> >> g.region: >> >> >> >> projection: 99 (Transverse Mercator) >> >> zone: 0 >> >> datum: ** unknown (default: WGS84) ** >> >> ellipsoid: wgs84 >> >> north: 2988300 >> >> south: 2959850 >> >> west: 74300 >> >> east: 99550 >> >> nsres: 25 >> >> ewres: 25 >> >> rows: 1138 >> >> cols: 1010 >> >> cells: 1149380 >> >> >> >> v.info: >> >> >> >> >> >> >> ++ >> >> | Layer: dem_2628cc_...@c83 >> >> | Mapset: C83 >> >> | Location:sa_tm_19deg_E >> >> | Database:C:\Hanlie\grassdata >> >> | Title: >> >> | Map scale: 1:1 >> >> | Map format: native >> >> | Name of creator: Administrator >> >> | Organization: >> >> | Source date: Thu May 13 16:06:07 2010 >> >> >> >> >> >> >> || >> >> | Type of Map: vector (level: 2) >> >> | >> >> | Number of points: 1151529 Number of areas: 0 >> >> | Number of lines:0 Number of islands:0 >> >> | Number of boundaries: 0 Number of faces: 0 >> >> | Number of centroids:0 Number of kernels:0 >> >> | >> >> | Map is 3D: Yes >> >> | Number of dblinks: 0 >> >> | >> >> | Projection: Transverse Mercator >> >> | N: 2988300S: 2959850 >> >> | E: 99550W: 74300 >> >> | B: 1429.79T:1740.2 >> >> | >> >> | Digitization threshold: 0 >> >> | Comments: >> >> | >> >> >> >> >> >> >> ++ >> >> >> >> r.info: >> >> >> >> >> >> >> ++ >> >> | Layer:dem_2628cc_...@c83 Date: Thu May 13 16:15:50 >> 2010 >> >> | Mapset: C83Login of Creator: >> >> Administrator >> >> | Location: sa_tm_19deg_E >> >> | DataBase: C:\Hanlie\grassdata >> >> | Title:Categories ( dem_2628cc_25m ) >> >> | Timestamp: none >> >> >> >> >> >> >> || >> >> | >> >>| >> >> | Type of Map: raster Number of Categories: 0 >> >> | Data Type:DCELL >> >> | Rows: 1138 >> >> | Columns: 1010 >> >> | Total Cells: 1149380 >> >> |Projection: Transverse Mercator >> >> |N:2988300S:2959850 Res:25 >> >> |
