[gdal-dev] Dateline gap
Jerl Simpson
jsimpson at wxtrends.com
Thu Apr 14 09:18:30 EDT 2011
Joaquim:
Ok that makes more sense now. You answered some of the questions I
was having, like how can ps2raster do anything with a necdf anyway?
I just used the info for that one test file, because the contents were
shorted.
It happens with others as well like this one that has these coordinates:
Corner Coordinates:
Upper Left (-180.2500000, 90.2500000)
Lower Left (-180.2500000, -90.2500000)
Upper Right ( 180.2500000, 90.2500000)
Lower Right ( 180.2500000, -90.2500000)
Center ( 0.0000000, 0.0000000)
I'll post questions on the GMT list as well.
Thanks
Jerl
On Thu, Apr 14, 2011 at 8:06 AM, Joaquim Luis <jluis at ualg.pt> wrote:
> Jerl,
>
> I suggested the ps2raster way because it's one that I know well (I'm
> supposed to) but probably there is also a GDAL solution (that I don't know).
> Since ps2raster is a GMT program I suggest that you make this questions in
> the GMT list. However, since I kind of start this I'll give some further
> infos here.
> Regarding the error message you got the explanation is simple. ps2raster
> takes a POSTSCRIPT file and converts it into other formats using ghoscript.
> If the ps file was created by GMT, it will detect the projection information
> stored as PS comments and use it to create a kml file (or geotiff btw). That
> means in principle ANY figure created with GMT and using plain geographical
> coordinates can be converted to KML. But you used ps2raster directly with
> the netcdf file, which is not possible at all. Finally, the netcdf file is a
> bit strange too. What are the coordinates?
> 0 512
> 0 512
> doesn't sound like real coordinates.
>
> Joaquim
>
>> Hello:
>>
>> I'm having a hard time getting anything to work with the files I have.
>> Maybe the files need to be changed or translated? Joaquim mentioned
>> they need to be in geogs but I'm not sure how to go about checking for
>> that or converting to that if need be. I've included output from one
>> of the tests I ran. It works the same way with all my files no matter
>> what the data inside is. One thing I thought was strange was that I
>> used the -A option, and in the error message it tells me to use the -A
>> options.
>>
>> Command:
>> ps2raster -A -D./tests -E720 -TG -V -W+k testNETCDF.nc
>>
>> Output:
>> ps2raster: Processing testNETCDF.nc: Find HiResBoundingBox Error:
>> /undefined in CDF
>> Operand stack:
>>
>> Execution stack:
>> %interp_exit .runexec2 --nostringval-- --nostringval--
>> --nostringval-- 2 %stopped_push --nostringval--
>> --nostringval-- --nostringval-- false 1 %stopped_push 1878
>> 1 3 %oparray_pop 1877 1 3 %oparray_pop 1861 1 3
>> %oparray_pop 1755 1 3 %oparray_pop --nostringval--
>> %errorexec_pop .runexec2 --nostringval-- --nostringval--
>> --nostringval-- 2 %stopped_push --nostringval--
>> Dictionary stack:
>> --dict:1151/1684(ro)(G)-- --dict:0/20(G)-- --dict:70/200(L)--
>> Current allocation mode is local
>> Current file position is 5
>> ps2raster: GMT FATAL ERROR: The file testNETCDF.nc has no BoundingBox
>> in the first 20 lines or last 256 bytes. Use -A option.
>>
>>
>> gdalinfo for netcdf:
>> Driver: netCDF/Network Common Data Format
>> Files: testNETCDF.nc
>> Size is 512, 512
>> Coordinate System is `'
>> Metadata:
>> NC_GLOBAL#Conventions=COARDS
>> NC_GLOBAL#calendar=standard
>> NC_GLOBAL#comments=File
>> NC_GLOBAL#model=geos/das
>> NC_GLOBAL#center=gsfc
>> Subdatasets:
>> SUBDATASET_1_NAME=NETCDF:"testNETCDF.nc":max_temp
>> SUBDATASET_1_DESC=[15x601x1201] max_temp (32-bit floating-point)
>> SUBDATASET_2_NAME=NETCDF:"testNETCDF.nc":min_temp
>> SUBDATASET_2_DESC=[15x601x1201] min_temp (32-bit floating-point)
>> SUBDATASET_3_NAME=NETCDF:"testNETCDF.nc":prcp
>> SUBDATASET_3_DESC=[15x601x1201] prcp (32-bit floating-point)
>> Corner Coordinates:
>> Upper Left ( 0.0, 0.0)
>> Lower Left ( 0.0, 512.0)
>> Upper Right ( 512.0, 0.0)
>> Lower Right ( 512.0, 512.0)
>> Center ( 256.0, 256.0)
>>
>> Thank you,
>>
>> Jerl
>>
>> On Tue, Apr 12, 2011 at 7:24 PM, Joaquim Luis<jluis at ualg.pt> wrote:
>>>
>>> Jerl,
>>>
>>> I would do that with GMT. By using ps2raster you can convert any GMT
>>> figure
>>> (in geogs of course) into KML, and GMT has excellent care of date line
>>> transition issues.
>>>
>>> Joaquim
>>>
>>>> Hello:
>>>>
>>>> I stopped by the #gdal channel on IRC to ask this question. Thank you
>>>> for the help provided there. I thought it might be better if I asked
>>>> a question here so I can better explain what's going on in one spot
>>>> and not flood the channel.
>>>> I understand this is a pixel center vs pixel edge issue.
>>>>
>>>> My ultimate goal is to get from a netCDF file to a google map overlay
>>>> contour.
>>>> The general steps I've taken, which work all the way up to about
>>>> 178.29 then it just cuts off.
>>>>
>>>> netCDF -> color-relief PNG using "gdaldem color-relief ... "
>>>> PNG -> Geocoded PNG using "gdal_translate -a_srs EPSG:4326 -outsize
>>>> 4096 4096 -a_ullr -180.25 90.25 180.25 -90.25" on the PNG (Have also
>>>> tried this with just "-180 90 180 -90"
>>>> PNG -> tiles using "gdal2tiles.py -s EPSG:4326 -z 0 -n -w google" on
>>>> the Geocoded PNG
>>>> I guess first question, is my methodology sound? Maybe there's a
>>>> better way/tool to approach the problem.
>>>>
>>>> Following is the output from gdalinfo, other than that, what
>>>> information might I be able to provide that could help?
>>>>
>>>> Thank you,
>>>>
>>>> Jerl
>>>>
>>>> gdalinfo for the source netcdf: (My apologies, I'm not certain what is
>>>> relevant so I'm including most everything.)
>>>>
>>>> Driver: netCDF/Network Common Data Format
>>>> Files: test.nc
>>>> Size is 721, 361
>>>> Coordinate System is `'
>>>> Origin = (-180.250000000000000,90.250000000000000)
>>>> Pixel Size = (0.500000000000000,-0.500000000000000)
>>>> Metadata:
>>>> NC_GLOBAL#Conventions=CF-1.0
>>>> NC_GLOBAL#cdm_data_type=GRID
>>>> NC_GLOBAL#file_format=GEMPAK
>>>> NC_GLOBAL#location=test.grd
>>>> NC_GLOBAL#history=Direct read of GEMPAK into NetCDF-Java 4.0 API
>>>> NC_GLOBAL#_CoordinateModelRunDate=2011-04-12T00:00:00Z
>>>> UVIN_NONE#long_name=testdata
>>>> UVIN_NONE#units=
>>>> UVIN_NONE#missing_value=-9.999000e+03
>>>> UVIN_NONE#VectorComponentFlag=gridRelative
>>>> time#long_name=forecast time
>>>> time#units=minute since 2011-04-12T00:00:00Z
>>>> time#_CoordinateAxisType=Time
>>>> lat#units=degrees_north
>>>> lat#long_name=latitude coordinate
>>>> lat#standard_name=latitude
>>>> lat#grid_spacing=0.5 degrees_north
>>>> lat#_CoordinateAxisType=Lat
>>>> lon#units=degrees_east
>>>> lon#long_name=longitude coordinate
>>>> lon#standard_name=longitude
>>>> lon#grid_spacing=0.5 degrees_east
>>>> lon#_CoordinateAxisType=Lon
>>>> Corner Coordinates:
>>>> Upper Left (-180.2500000, 90.2500000)
>>>> Lower Left (-180.2500000, -90.2500000)
>>>> Upper Right ( 180.2500000, 90.2500000)
>>>> Lower Right ( 180.2500000, -90.2500000)
>>>> Center ( 0.0000000, 0.0000000)
>>>>
>>>> gdalinfo of geocoded PNG:
>>>>
>>>> Driver: PNG/Portable Network Graphics
>>>> Files: testWorld.png
>>>> testWorld.png.aux.xml
>>>> Size is 4096, 4096
>>>> Coordinate System is:
>>>> GEOGCS["WGS 84",
>>>> DATUM["WGS_1984",
>>>> SPHEROID["WGS 84",6378137,298.257223563,
>>>> AUTHORITY["EPSG","7030"]],
>>>> AUTHORITY["EPSG","6326"]],
>>>> PRIMEM["Greenwich",0,
>>>> AUTHORITY["EPSG","8901"]],
>>>> UNIT["degree",0.01745329251994328,
>>>> AUTHORITY["EPSG","9122"]],
>>>> AUTHORITY["EPSG","4326"]]
>>>> Origin = (-180.000000000000000,90.000000000000000)
>>>> Pixel Size = (0.087890625000000,-0.043945312500000)
>>>> Image Structure Metadata:
>>>> INTERLEAVE=PIXEL
>>>> Corner Coordinates:
>>>> Upper Left (-180.0000000, 90.0000000) (180d 0'0.00"W, 90d 0'0.00"N)
>>>> Lower Left (-180.0000000, -90.0000000) (180d 0'0.00"W, 90d 0'0.00"S)
>>>> Upper Right ( 180.0000000, 90.0000000) (180d 0'0.00"E, 90d 0'0.00"N)
>>>> Lower Right ( 180.0000000, -90.0000000) (180d 0'0.00"E, 90d 0'0.00"S)
>>>> Center ( 0.0000000, 0.0000000) ( 0d 0'0.01"E, 0d 0'0.01"N)
>>>> Band 1 Block=4096x1 Type=Byte, ColorInterp=Red
>>>> Mask Flags: PER_DATASET ALPHA
>>>> Band 2 Block=4096x1 Type=Byte, ColorInterp=Green
>>>> Mask Flags: PER_DATASET ALPHA
>>>> Band 3 Block=4096x1 Type=Byte, ColorInterp=Blue
>>>> Mask Flags: PER_DATASET ALPHA
>>>> Band 4 Block=4096x1 Type=Byte, ColorInterp=Alpha
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
--
This communication is privileged and may contain confidential
information. It's intended only for the use of the person or entity
named above. If you are not the intended recipient, do not distribute
or copy this communication. If you have received this communication in
error, please notify the sender immediately and return the original to
the email address above. © Copyright 2011 Weather Trends
International, Inc.
More information about the gdal-dev
mailing list