<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jeff,<br>
<br>
Are you by chance using TIFFs produced using Intergraph's ISRU tools?
If so, the special Intergraph format of the TIFFs may make them
unusable with MGOS. They are definitely not compatible with the older
MapGuide 6.x software.<br>
<br>
Carl<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Jeff_Hobbs@sjwater.com">Jeff_Hobbs@sjwater.com</a> wrote:
<blockquote
cite="midOF34625E82.01EA29EA-ON0825728A.006680A0@sjwater.com"
type="cite">
<pre wrap="">All,
If anybody is curious, when I translated the image documented below to ECW
using the free compressor, it came up just fine in MGOS. Apparently the
Raster FDO has large problems with my TIFFs. Not sure if it's the tiling,
overviews/pyramids, or maybe even the compression.
Anyhow, just wanted to pass along the information.
Jeff
--------------------------------------
Andy/All
Thanks for the replies. I'm very new to MG so I was hoping for a little
clarification/verification on my understanding from reading the threads.
I come from an Intergraph background. In that world, they prefer many
small images as opposed to one giant image. Additionally they prefer TIFFs
as opposed to ECW or other compressed formats. The TIFFS should have a
full set of overviews/pyramids and also be tiled. With the TIFF, it can be
compressed, but does impact the speed some. I've always been told that the
reasoning behind this is because it takes additional time to decompress
the image to feed to the client application.
I guess I mention this because it sounds like MG actually prefers ECWs
OVER TIFFs, is this correct?
I've attempted to keep the issue of "process thousands of images per map
request" by setting a scale dependency. However it sounds like MGOS does
not store the MBRs for each image in an index. I've seen the term "Raster
Catalog" in the MG Studio help. It sounds like there's currently no way
with MGOS to build this "catalog". As a result, it's still going to need
to scan all the images in the folder(s) before providing the results,
correct?
I guess with all that said, I still can't get MGOS to see even ONE image.
I've only selected one image in the "Data Files" section of my Data
Connection in MG Studio. The image falls underneath vectors in the same
area so I assume my coordinates are correct in the "Initial View" section
of my map. The image is a GeoTIFF. The GeoTIFF header information is
below. Has anybody tested MGOS with compressed TIFFs with tiles/overviews?
I will update my server with the latest GDAL ECW and then covert one of
the TIFFs to ECW and see if that works better.
Thoughts?
--------------------------------------------------------------------------
----------------------------
Output from Display Header
File Name: \\gisdb\GIS Imagery\2001 SCLARCO Orthos\9 Inch\61145_18930.tif
File Information:
Standard : : TIFF File
Format : : JPEG Compressed 24 bit RGB data, Q= 25
Pixels per Line : 2000
Number of Lines : 2000
Samples per pixel : 3
File bits per sample : 8
Actual bits per sample : 8
Tiled file, tile dimension : 512
Number of tiles along a row : 4
Number of tile rows : 4
Number of overviews : 7
Overview sampling method: Averaged
Scanning device resolution : 72 : lines/inch
Orientation : 4 : Row major order, origin at top left
NO scan line headers : non-scannable file
Packet size (16-bit words) : 108
Free vlt space (16-bit words) : 2000000000
Free packet space (16-bit words) : 2000000000
Raster to UOR matrix:
mx[ 0]=75.000000, mx[ 1]=0.000000, mx[ 2]=0.000000, mx[
3]=611450000.000000
mx[ 4]=0.000000, mx[ 5]=75.000000, mx[ 6]=0.000000, mx[
7]=189450000.000000
mx[ 8]=0.000000, mx[ 9]=0.000000, mx[10]=1.000000, mx[11]=0.000000
mx[12]=0.000000, mx[13]=0.000000, mx[14]=0.000000, mx[15]=1.000000
Raster to World Matrix:
Units: Survey Feet
amx[ 0]=0.750000000360112, amx[ 1]= 0, amx[ 2]=
6114500
amx[ 3]= 0, amx[ 4]=-0.749999999978173, amx[ 5]=
1894500
6114500 , 1894500
6116000.00000072 , 1894500
6116000.00000072 , 1893000.00000004
6114500 , 1893000.00000004
Intergraph Packet Data:
Matrix packet Type=2, Subtype=10, Size=104
Geotiff_Information:
Version: 1
Key_Revision: 1.0
Tagged_Information:
ModelTiepointTag (2,3):
0 0 0
6114500 1894500 0
ModelPixelScaleTag (1,3):
0.75 0.75 0
End_Of_Tags.
Keyed_Information:
GTModelTypeGeoKey (Short,1): ModelTypeProjected
GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
GeogGeodeticDatumGeoKey (Short,1): Datum_North_American_Datum_1983
GeogEllipsoidGeoKey (Short,1): Ellipse_GRS_1980
ProjNatOriginLongGeoKey (Double,1): -120.5
ProjNatOriginLatGeoKey (Double,1): 36.5
ProjFalseEastingGeoKey (Double,1): 6561666.67
ProjFalseNorthingGeoKey (Double,1): 1640416.67
ProjScaleAtNatOriginGeoKey (Double,1): 1
PCSCitationGeoKey (Ascii,82): "State Plane Coordinate System 1983;
North American 1983; GRS80; Zone California 3"
ProjectedCSTypeGeoKey (Short,1): PCS_NAD83_California_3
ProjLinearUnitsGeoKey (Short,1): Linear_Foot_US_Survey
End_Of_Keys.
End_Of_Geotiff.
PCS = 26943 (NAD83 / California zone 3)
Projection = 10433 (SPCS83 California zone 3 (meters))
Projection Method: CT_LambertConfConic_2SP
ProjFalseOriginLatGeoKey: 36.500000 ( 36d30' 0.00"N)
ProjFalseOriginLongGeoKey: -120.500000 (120d30' 0.00"W)
ProjStdParallel1GeoKey: 38.433333 ( 38d26' 0.00"N)
ProjStdParallel2GeoKey: 37.066667 ( 37d 4' 0.00"N)
ProjFalseEastingGeoKey: 2000000.000000 m
ProjFalseNorthingGeoKey: 500000.000000 m
GCS: 4269/NAD83
Datum: 6269/North American Datum 1983
Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31)
Prime Meridian: 8901/Greenwich (0.000000/ 0d 0' 0.00"E)
Projection Linear Units: 9003/US survey foot (0.304801m)
Corner Coordinates:
Upper Left (6114500.000,1894500.000)
Lower Left (6114500.000,1893000.000)
Upper Right (6116000.000,1894500.000)
Lower Right (6116000.000,1893000.000)
Center (6115250.000,1893750.000)
--------------------------------------------------------------------------
-------------------------------------------------------
--------------------------------
Jeff Hobbs
GIS Supervisor
San Jose Water Company (NYSE:SJW)
1265 South Bascom Avenue
San Jose, CA 95128
Voice - (408) 279-7833
Fax - (408) 279-7889
<a class="moz-txt-link-abbreviated" href="mailto:jeff_hobbs@sjwater.com">jeff_hobbs@sjwater.com</a>
<a class="moz-txt-link-freetext" href="http://www.sjwater.com">http://www.sjwater.com</a>
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:mapguide-users-bounces@lists.osgeo.org">mapguide-users-bounces@lists.osgeo.org</a>
[<a class="moz-txt-link-freetext" href="mailto:mapguide-users-bounces@lists.osgeo.org">mailto:mapguide-users-bounces@lists.osgeo.org</a>] On Behalf Of Andy Morsell
Sent: Wednesday, February 21, 2007 17:49
To: 'MapGuide Users Mail List'
Subject: RE: SPAM-LOW: RE: [mapguide-users] Problem with OS Geo FDO
Provider for Raster.
The link to the Autodesk whitepaper only pertains to the Autodesk raster
provider. The GDAL provider, in essence, works that way by default.
I have a feeling with 50,000 images approaching a Terabyte, that MapGuide
and the GDAL provider simply won't handle this well for dynamically
serving the data. You should strongly consider pre-processing your data
into formats more suitable for this type of an application. This would
include mosaicing your data into county-wide wavelet compressed images. I
personally would recommend using ECW format, although MrSID would also
work well. By doing this, you eliminate the software having to open and
process possibly thousands of images per map request. As the user zooms
in further, you might be able to switch to a layer that does display these
higher resolution images, however. My understanding is that the GDAL
provider currently does not handle the indexing of many images in a
directory well, so you may find this is not optimal at the moment.
Andy Morsell, P.E.
Spatial Integrators, Inc.
<a class="moz-txt-link-freetext" href="http://www.SpatialGIS.com">http://www.SpatialGIS.com</a>
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:mapguide-users-bounces@lists.osgeo.org">mapguide-users-bounces@lists.osgeo.org</a>
[<a class="moz-txt-link-freetext" href="mailto:mapguide-users-bounces@lists.osgeo.org">mailto:mapguide-users-bounces@lists.osgeo.org</a>] On Behalf Of
<a class="moz-txt-link-abbreviated" href="mailto:Jeff_Hobbs@sjwater.com">Jeff_Hobbs@sjwater.com</a>
Sent: Wednesday, February 21, 2007 5:19 PM
To: <a class="moz-txt-link-abbreviated" href="mailto:mapguide-users@lists.osgeo.org">mapguide-users@lists.osgeo.org</a>
Subject: SPAM-LOW: RE: [mapguide-users] Problem with OS Geo FDO Provider
for Raster.
All,
I'm a bit confused on how to get MG Studio to read my orthos. I'm running
MGOS 1.1.0 and have applied the GDAL patch.
A little background -
I have three inch and nine inch imagery for much of Santa Clara County,
CA.
It's quite a bit of data - rounding up about 1 tb. It is NOT sitting on my
web server.
My initial thought was to use MG Studio OSGeo.Gdal provider. I have set
the DefaultRasterFileLocation to my server with my images. I provided a
domain user name and password. I assume with this information, MGOS should
be able to access the remote server. I also selected just a few files to
ensure a fast test. The test works - but does take some time.
I've created a layer referencing the feature source. I've add the layer to
a map. I set the extents to be the same as other layers on the map. I also
set the display scale reference to be between 1,000 and 300.
When I load the map, it loads fine initially. When I zoom into a scale
about 1,000, the browser locks up after a few minutes I get a "status code
503 - server too busy" error and my MGOS service dies.
Any ideas on what I'm missing? Should I follow this workflow instead:
<a class="moz-txt-link-freetext" href="http://images.autodesk.com/adsk/files/linking_to_external_data_autodeskmap">http://images.autodesk.com/adsk/files/linking_to_external_data_autodeskmap</a>
guidewhitepaper.pdf? If so, do I have to list each image individually?
There's maybe 50,000 images. That would just be painful.
Thoughts?
Thanks!
Jeff
--------------------------------
Jeff Hobbs
GIS Supervisor
San Jose Water Company (NYSE:SJW)
1265 South Bascom Avenue
San Jose, CA 95128
Voice - (408) 279-7833
Fax - (408) 279-7889
<a class="moz-txt-link-abbreviated" href="mailto:jeff_hobbs@sjwater.com">jeff_hobbs@sjwater.com</a>
<a class="moz-txt-link-freetext" href="http://www.sjwater.com">http://www.sjwater.com</a>
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:mapguide-users-bounces@lists.osgeo.org">mapguide-users-bounces@lists.osgeo.org</a>
[<a class="moz-txt-link-freetext" href="mailto:mapguide-users-bounces@lists.osgeo.org">mailto:mapguide-users-bounces@lists.osgeo.org</a>] On Behalf Of Andy Morsell
Sent: Wednesday, February 21, 2007 09:19
To: 'MapGuide Users Mail List'
Subject: Re: [mapguide-users] Problem with OS Geo FDO Provider for Raster.
The binary patch can be found under the "Windows Installers" section of
this
page: <a class="moz-txt-link-freetext" href="http://mapguide.osgeo.org/downloads.html">http://mapguide.osgeo.org/downloads.html</a>
Andy
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:mapguide-users-bounces@lists.osgeo.org">mapguide-users-bounces@lists.osgeo.org</a>
[<a class="moz-txt-link-freetext" href="mailto:mapguide-users-bounces@lists.osgeo.org">mailto:mapguide-users-bounces@lists.osgeo.org</a>] On Behalf Of Frank
Warmerdam
Sent: Wednesday, February 21, 2007 9:11 AM
To: MapGuide Users Mail List
Subject: SPAM-LOW: Re: [mapguide-users] Problem with OS Geo FDO Provider
for Raster.
Maciej Skorczewski wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi all!
I use MGOS 1.1.0
When i load raster whit FDO Provider for Raster i can't make zoom to
raster layer... raster take a diferent shape. I use Ajax tiled base.
</pre>
</blockquote>
<pre wrap=""><!---->
Maciej,
There was a binary build provided with a fix for this problem, but I see
that the source on the download site has not been updated. I think you
can safely pull down the fdogdal source from the 3.2.1 subversion branch
to get this fix.
I'm not exactly sure where the binary patch is that was provided. But if
you install:
<a class="moz-txt-link-freetext" href="http://www.gdal.org/dl/mapguide/mg_mrsid_110.zip">http://www.gdal.org/dl/mapguide/mg_mrsid_110.zip</a>
then you should also get the fix.
Best regards,
</pre>
</blockquote>
</body>
</html>