[gdal-dev] Dateline gap
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.250,90.250) Pixel Size = (0.500,-0.500) 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.250, 90.250) Lower Left (-180.250, -90.250) Upper Right ( 180.250, 90.250) Lower Right ( 180.250, -90.250) Center ( 0.000, 0.000) 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.000,90.000) Pixel Size = (0.08789062500,-0.04394531250) Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left (-180.000, 90.000) (180d 0'0.00"W, 90d 0'0.00"N) Lower Left (-180.000, -90.000) (180d 0'0.00"W, 90d 0'0.00"S) Upper Right ( 180.000, 90.000) (180d 0'0.00"E, 90d 0'0.00"N) Lower Right ( 180.000, -90.000) (180d 0'0.00"E, 90d 0'0.00"S) Center ( 0.000, 0.000) ( 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. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Dateline gap
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.250,90.250) Pixel Size = (0.500,-0.500) 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.250, 90.250) Lower Left (-180.250, -90.250) Upper Right ( 180.250, 90.250) Lower Right ( 180.250, -90.250) Center ( 0.000, 0.000) 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.000,90.000) Pixel Size = (0.08789062500,-0.04394531250) Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left (-180.000, 90.000) (180d 0'0.00"W, 90d 0'0.00"N) Lower Left (-180.000, -90.000) (180d 0'0.00"W, 90d 0'0.00"S) Upper Right ( 180.000, 90.000) (180d 0'0.00"E, 90d 0'0.00"N) Lower Right ( 180.000, -90.000) (180d 0'0.00"E, 90d 0'0.00"S) Center ( 0.000, 0.000) ( 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Dateline gap
Thanks for the GMT suggestions. I've never used it, I'll try it out. Thanks!! Typed with thumbs... On Apr 12, 2011 7:24 PM, "Joaquim Luis" 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.250,90.250) >> Pixel Size = (0.500,-0.500) >> 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.250, 90.250) >> Lower Left (-180.250, -90.250) >> Upper Right ( 180.250, 90.250) >> Lower Right ( 180.250, -90.250) >> Center ( 0.000, 0.000) >> >> 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.000,90.000) >> Pixel Size = (0.08789062500,-0.04394531250) >> Image Structure Metadata: >> INTERLEAVE=PIXEL >> Corner Coordinates: >> Upper Left (-180.000, 90.000) (180d 0'0.00"W, 90d 0'0.00"N) >> Lower Left (-180.000, -90.000) (180d 0'0.00"W, 90d 0'0.00"S) >> Upper Right ( 180.000, 90.000) (180d 0'0.00"E, 90d 0'0.00"N) >> Lower Right ( 180.000, -90.000) (180d 0'0.00"E, 90d 0'0.00"S) >> Center ( 0.000, 0.000) ( 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 >> >> >> > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Dateline gap
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 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.250,90.250) >> Pixel Size = (0.500,-0.500) >> 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.250, 90.250) >> Lower Left (-180.250, -90.250) >> Upper Right ( 180.250, 90.250) >> Lo
Re: [gdal-dev] Dateline gap
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 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.250,90.250) Pixel Size = (0.500,-0.500) 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
Re: [gdal-dev] Dateline gap
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.250, 90.250) Lower Left (-180.250, -90.250) Upper Right ( 180.250, 90.250) Lower Right ( 180.250, -90.250) Center ( 0.000, 0.000) I'll post questions on the GMT list as well. Thanks Jerl On Thu, Apr 14, 2011 at 8:06 AM, Joaquim Luis 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 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 >>>
