Wonky numeric ranges for models at Thinklab shell

[lambdatronic]

These two models return extremely strange values at the Thinklab shell. Please take a look. The only similar feature I can recall is that both were overridden by global layers before I added metadata:hasPriority properties to their kbox XML blobs.

> model -d core.models.water-ontario/altitude core.contexts.ontario/lakeofthewoods-wgs84
3 possible observation(s) found
2012-02-24 13:43:12,368 [main] INFO  org.integratedmodelling.geospace.Geospace reading WCS source http://ecoinformatics.uvm.edu/geoserver/wcs#ontario:dem20m_low
accessing: http://ecoinformatics.uvm.edu/geoserver/wcs?service=WCS&version=1.0.0&request=DescribeCoverage&coverage=ontario:dem20m_low
2012-02-24 13:43:12,393 [main] INFO  org.integratedmodelling.geospace.Geospace parsing descriptor for ontario:dem20m_low
WCS URL: http://ecoinformatics.uvm.edu/geoserver/wcs?service=WCS&version=1.0.0&request=GetCoverage&coverage=ontario:dem20m_low&bbox=-94.48,48.869794921875,-93.63,49.190205078125&crs=EPSG:4326&responseCRS=EPSG:4326&width=512&height=193&format=geotiff
Spatially distributed on a 512 by 193 raster grid (cell area = 23,121.193 m²)
----------------------------------------------------------------------------
geophysics:Altitude
----------------------------------------------------------------------------
[-340,282,346,638,528,860,000,000,000,000,000,000,000 -306,254,111,974,675,970,000,000,000,000,000,000,000] ||   10042
[-306,254,111,974,675,970,000,000,000,000,000,000,000 -272,225,877,310,823,100,000,000,000,000,000,000,000] ||       0
[-272,225,877,310,823,100,000,000,000,000,000,000,000 -238,197,642,646,970,200,000,000,000,000,000,000,000] ||       0
[-238,197,642,646,970,200,000,000,000,000,000,000,000 -204,169,407,983,117,300,000,000,000,000,000,000,000] ||       0
[-204,169,407,983,117,300,000,000,000,000,000,000,000 -170,141,173,319,264,430,000,000,000,000,000,000,000] ||       0
[-170,141,173,319,264,430,000,000,000,000,000,000,000 -136,112,938,655,411,540,000,000,000,000,000,000,000] ||       0
[-136,112,938,655,411,540,000,000,000,000,000,000,000 -102,084,703,991,558,660,000,000,000,000,000,000,000] ||       0
[-102,084,703,991,558,660,000,000,000,000,000,000,000 -68,056,469,327,705,770,000,000,000,000,000,000,000]  ||       0
[-68,056,469,327,705,770,000,000,000,000,000,000,000 -34,028,234,663,852,886,000,000,000,000,000,000,000]   ||       0
[-34,028,234,663,852,886,000,000,000,000,000,000,000 0]                                                     ||   88774
----------------------------------------------------------------------------
no-data                                                                                                     ||       0
Aggregated over 1,354.393 km²: 208.548 m

> rank -d habitat:PercentTreeCanopyCover core.contexts.ontario/lakeofthewoods-wgs84
3 possible model(s) found
2012-02-24 13:46:39,096 [main] INFO  org.integratedmodelling.geospace.Geospace reading WCS source http://ecoinformatics.uvm.edu/geoserver/wcs#ontario:canopy_low
accessing: http://ecoinformatics.uvm.edu/geoserver/wcs?service=WCS&version=1.0.0&request=DescribeCoverage&coverage=ontario:canopy_low
2012-02-24 13:46:39,121 [main] INFO  org.integratedmodelling.geospace.Geospace parsing descriptor for ontario:canopy_low
WCS URL: http://ecoinformatics.uvm.edu/geoserver/wcs?service=WCS&version=1.0.0&request=GetCoverage&coverage=ontario:canopy_low&bbox=-94.48,48.869794921875,-93.63,49.190205078125&crs=EPSG:4326&responseCRS=EPSG:4326&width=512&height=193&format=geotiff
Spatially distributed on a 512 by 193 raster grid (cell area = 23,121.193 m²)
----------------------------------------------------------------------------
habitat:PercentTreeCanopyCover
----------------------------------------------------------------------------
[-340,282,346,638,528,860,000,000,000,000,000,000,000 -306,254,111,974,675,970,000,000,000,000,000,000,000] ||   10016
[-306,254,111,974,675,970,000,000,000,000,000,000,000 -272,225,877,310,823,100,000,000,000,000,000,000,000] ||       0
[-272,225,877,310,823,100,000,000,000,000,000,000,000 -238,197,642,646,970,200,000,000,000,000,000,000,000] ||       0
[-238,197,642,646,970,200,000,000,000,000,000,000,000 -204,169,407,983,117,300,000,000,000,000,000,000,000] ||       0
[-204,169,407,983,117,300,000,000,000,000,000,000,000 -170,141,173,319,264,430,000,000,000,000,000,000,000] ||       0
[-170,141,173,319,264,430,000,000,000,000,000,000,000 -136,112,938,655,411,540,000,000,000,000,000,000,000] ||       0
[-136,112,938,655,411,540,000,000,000,000,000,000,000 -102,084,703,991,558,660,000,000,000,000,000,000,000] ||       0
[-102,084,703,991,558,660,000,000,000,000,000,000,000 -68,056,469,327,705,770,000,000,000,000,000,000,000]  ||       0
[-68,056,469,327,705,770,000,000,000,000,000,000,000 -34,028,234,663,852,886,000,000,000,000,000,000,000]   ||       0
[-34,028,234,663,852,886,000,000,000,000,000,000,000 0]                                                     ||   48047
----------------------------------------------------------------------------
no-data                                                                                                     ||   40753

[lambdatronic]

@bvoigt @fvilla @lambdatronic

Adding other folks to this ticket.

[fvilla]

I had already told Brian before this was posted - it means that whatever data layer gets picked up doesn't have its nodata values set properly in the XML (and in the GIS file, as these would be automatically there if the GIS metadata contained them). The giant negative bottom value is the usual nodata value for double values. A line like geospace:hasNodataValue-3.4028234663852886E38/geospace:hasNodataValue in the datasource specs usually does the trick. And that being a GIS issue, it really shouldn't need to be solved by me every single time it appears, but OK.

[kbagstad]

OK, so posting on a closed issue, but Gary and especially Brian be aware that Arc in particular tends to hide these funky nodata values. It's good practice if you're prepping data in arc to view it in Geoserver's layer preview or in another GIS package (I've found udig to be good at this) and click on some points just outside your actual (known good) data. Oftentimes they'll show up as these goofy values and you'll need to insert the xml tag that Ferd mentions above. Common goofy values are the -3.4...E38, 255.0, 128.0, etc. A simple step you can do to save yourself some modeling heartburn.

[bvoigt]

Hey Ken - I assume you're referring to raster data here? If that's the case, when you export a raster to a TIFF (in ArcGIS), there is an option in the dialogue box where you can specify the No Data value. Could be easier to deal with the value here where you have some control over it, as opposed to a fishing expedition after the data has been prepped. In any case, I appreciate the heads up. brian

On 2/28/2012 1:09 AM, kbagstad wrote:

OK, so posting on a closed issue, but Gary and especially Brian be aware that Arc in particular tends to hide these funky nodata values. It's good practice if you're prepping data in arc to view it in Geoserver's layer preview or in another GIS package (I've found udig to be good at this) and click on some points just outside your actual (known good) data. Oftentimes they'll show up as these goofy values and you'll need to insert the xml tag that Ferd mentions above. Common goofy values are the -3.4...E38, 255.0, 128.0, etc. A simple step you can do to save yourself some modeling heartburn.

---

Reply to this email directly or view it on GitHub: https://github.com/ariesteam/aries/issues/58#issuecomment-4210250

[kbagstad]

That's right, I am referring to rasters. I'll keep the export to raster option in mind, it's a good suggestion.

[bvoigt]

see attached. brian

On 2/28/2012 12:11 PM, kbagstad wrote:

That's right, I am referring to rasters. I'll keep the export to raster option in mind, it's a good suggestion.

---

Reply to this email directly or view it on GitHub: https://github.com/ariesteam/aries/issues/58#issuecomment-4220365

[kbagstad]

Is there an attachment here? I don't think github will let you do those. If there's something you need to send just do it along with a general email. BTW on another non-github-related issue today is National Pancake Day, so it's ironic that you asked about it on our morning call.