[mapguide-users] Problem with OS Geo FDO Provider for Raster - UPDATE

Carl Von Stetten vonner.lists at vonner.net
Thu Feb 22 18:11:42 EST 2007


Jeff,

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.

Carl

Jeff_Hobbs at sjwater.com wrote:
> 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
> jeff_hobbs at sjwater.com
> http://www.sjwater.com
>
> -----Original Message-----
> From: mapguide-users-bounces at lists.osgeo.org
> [mailto:mapguide-users-bounces at lists.osgeo.org] 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.
> http://www.SpatialGIS.com
>
> -----Original Message-----
> From: mapguide-users-bounces at lists.osgeo.org
> [mailto:mapguide-users-bounces at lists.osgeo.org] On Behalf Of
> Jeff_Hobbs at sjwater.com
> Sent: Wednesday, February 21, 2007 5:19 PM
> To: mapguide-users at lists.osgeo.org
> 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:
> http://images.autodesk.com/adsk/files/linking_to_external_data_autodeskmap
> 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
> jeff_hobbs at sjwater.com
> http://www.sjwater.com
>
> -----Original Message-----
> From: mapguide-users-bounces at lists.osgeo.org
> [mailto:mapguide-users-bounces at lists.osgeo.org] 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: http://mapguide.osgeo.org/downloads.html 
>
>
> Andy 
>
> -----Original Message-----
> From: mapguide-users-bounces at lists.osgeo.org
> [mailto:mapguide-users-bounces at lists.osgeo.org] 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:
>   
>> 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.
>>     
>
> 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:
>
>     http://www.gdal.org/dl/mapguide/mg_mrsid_110.zip
>
> then you should also get the fix.
>
> Best regards,
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide-users/attachments/20070222/12c5180a/attachment-0001.html


More information about the mapguide-users mailing list