Re: [Geoserver-devel] Image pyramid improvements and tutorial
On Wed, Mar 31, 2010 at 11:25 PM, Stephen V. Mather s...@clevelandmetroparks.com wrote: Hmm, the embarassment of naïve configuration... . :D Let me do some additional testing on my end. I assume then that you got the image pyramid plugin to work without a special version of GeoServer? Yes, at least here. I did not spend too much time on testing yet (not a lot of spare time around here) but I just used a 2.0.x nightly. Simone. Thanks, Steve -Original Message- From: Andrea Aime [mailto:aa...@opengeo.org] Sent: Monday, March 29, 2010 2:25 PM To: s...@clevelandmetroparks.com Cc: 'Simone Giannecchini'; geoserver-devel@lists.sourceforge.net Subject: Re: [Geoserver-devel] Image pyramid improvements and tutorial Stephen V. Mather ha scritto: Hi Simone, The correct CRS is EPSG:3728, http://spatialreference.org/ref/epsg/3728/, although EPSG:102722 is pretty close. The size of the tiff is, well, either cheapness or laziness. The current format, naming convention and size is what has been used by our engineers in CAD for 8 years, and is referenced by all their CAD drawings, and I'm trying to not have two copies of a 160GB dataset. That said, if there's a strong performance gain to be had by retiling to a smaller size, I can squeeze more space out of our RAID. Hi Stephen, tried another time, and I could also build the pyramid correctly, though first I wiped out all the shapefiles and property files you did attach so that the pyramd plugin could perform its job. I can see the data just fine after that, though the rendering is quite slow. The TIFFs are not really very well setup, they do have no inner tiling, yet, I'm a bit surprised about the slowness. Looked into it and the reason is that a reprojection is happening, this is due to the native definition inside the GeoTiff not matching the official EPSG one. gdalinfo reports: PROJCS[NAD_1983_StatePlane_Ohio_North_FIPS_3401_Feet, GEOGCS[NAD83, DATUM[North_American_Datum_1983, SPHEROID[GRS 1980,6378137,298.2572221010002, AUTHORITY[EPSG,7019]], AUTHORITY[EPSG,6269]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4269]], PROJECTION[Lambert_Conformal_Conic_2SP], PARAMETER[standard_parallel_1,40.43], PARAMETER[standard_parallel_2,41.7], PARAMETER[latitude_of_origin,39.66], PARAMETER[central_meridian,-82.5], PARAMETER[false_easting,1968500], PARAMETER[false_northing,0], UNIT[US survey foot,0.3048006096012192, AUTHORITY[EPSG,9003]]] whilst the EPSG database contains: PROJCS[NAD83(NSRS2007) / Ohio North (ftUS), GEOGCS[NAD83(NSRS2007), DATUM[NAD83 (National Spatial Reference System 2007), SPHEROID[GRS 1980, 6378137.0, 298.257222101, AUTHORITY[EPSG,7019]], TOWGS84[0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0], AUTHORITY[EPSG,6759]], PRIMEM[Greenwich, 0.0, AUTHORITY[EPSG,8901]], UNIT[degree, 0.017453292519943295], AXIS[Geodetic longitude, EAST], AXIS[Geodetic latitude, NORTH], AUTHORITY[EPSG,4759]], PROJECTION[Lambert Conic Conformal (2SP), AUTHORITY[EPSG,9802]], PARAMETER[central_meridian, -82.5], PARAMETER[latitude_of_origin, 39.664], PARAMETER[standard_parallel_1, 41.7], PARAMETER[false_easting, 1968500.0], PARAMETER[false_northing, 0.0], PARAMETER[scale_factor, 1.0], PARAMETER[standard_parallel_2, 40.43], UNIT[foot_survey_us, 0.30480060960121924], AXIS[Easting, EAST], AXIS[Northing, NORTH], AUTHORITY[EPSG,3728]] As you can see there are quite a bit of parameters that are not equal. To get decent performance you'd need to reproject the tiles to an officially supported EPSG code, or create a new one in $GEOSERVER_DATA_DIR/user_projections/epsg.properties that matches 1-1 the WKT of your data Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___
[Geoserver-devel] IOUtils.zipDirectory issue
Hey, for the GeoNode process I'm using the org.geoserver.data.util.IOUtils.zipDirectory method (indirectly through shape-zipping). Problem is that this method is taking ownership of its argument ZipOutputStream since its calling zipout.finish(), essentially preventing the calling code (which owns the zip output stream) to append more content to the zip archive. As far as I can tell the only code using this is the ShapeZipOutputFormat? (for which I'm going to propose a refactor in a separate email). So I would like to prevent the utility method from calling ZipOutputStream.finish() at all and instead leave the responsibility to the calling code, which I think would be more appropriate. thoughts? Cheers, Gabriel -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Image pyramid improvements and tutorial
Stephen V. Mather ha scritto: Hmm, the embarassment of naïve configuration... . :D Let me do some additional testing on my end. I assume then that you got the image pyramid plugin to work without a special version of GeoServer? Correct, just took a nightly build, pointed it at the cleaned up test directory (the first one that has tiles inside), after removing all shapefiles, all property files. However performance wise the result is not really usable, the reprojection is quite heavy Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] IOUtils.zipDirectory issue
Gabriel Roldan ha scritto: Hey, for the GeoNode process I'm using the org.geoserver.data.util.IOUtils.zipDirectory method (indirectly through shape-zipping). Problem is that this method is taking ownership of its argument ZipOutputStream since its calling zipout.finish(), essentially preventing the calling code (which owns the zip output stream) to append more content to the zip archive. As far as I can tell the only code using this is the ShapeZipOutputFormat? (for which I'm going to propose a refactor in a separate email). Dangerous business, every time I touch that class it breaks in some way (it's handling a ton of use cases) So I would like to prevent the utility method from calling ZipOutputStream.finish() at all and instead leave the responsibility to the calling code, which I think would be more appropriate. Works for me Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] IOUtils.zipDirectory issue
So I would like to prevent the utility method from calling ZipOutputStream.finish() at all and instead leave the responsibility to the calling code, which I think would be more appropriate. Works for me Ok cool. GeoNode is using 2.0.2 so I would need to apply to the stable branch. Concerns? Cheers Andrea -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] IOUtils.zipDirectory issue
Gabriel Roldan ha scritto: So I would like to prevent the utility method from calling ZipOutputStream.finish() at all and instead leave the responsibility to the calling code, which I think would be more appropriate. Works for me Ok cool. GeoNode is using 2.0.2 so I would need to apply to the stable branch. Concerns? None, it's a one liner, no? Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] ShapeZipOutputFormat refactoring [Re: IOUtils.zipDirectory issue]
On 4/1/10 3:35 AM, Andrea Aime wrote: Gabriel Roldan ha scritto: As far as I can tell the only code using this is the ShapeZipOutputFormat? (for which I'm going to propose a refactor in a separate email). Dangerous business, every time I touch that class it breaks in some way (it's handling a ton of use cases) Well, intent is only to decouple the outputformat business from the actual shape-zipping process. Attempt results in the following patch: http://pastebin.com/RzkeVmeJ Meaning the output format write method ends up as: http://pastebin.com/4yNZxQKe and the utility class as http://pastebin.com/FtXS8YVz. Rationale being I need exactly this functionality for a geonode process (the one in the utility class) but not the wfs output format's specific concerns, and I would better avoid just copying and pasting? comments welcomed. Cheers, Gabriel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] ShapeZipOutputFormat refactoring [Re: IOUtils.zipDirectory issue]
Gabriel Roldan ha scritto: On 4/1/10 3:35 AM, Andrea Aime wrote: Gabriel Roldan ha scritto: As far as I can tell the only code using this is the ShapeZipOutputFormat? (for which I'm going to propose a refactor in a separate email). Dangerous business, every time I touch that class it breaks in some way (it's handling a ton of use cases) Well, intent is only to decouple the outputformat business from the actual shape-zipping process. Attempt results in the following patch: http://pastebin.com/RzkeVmeJ Meaning the output format write method ends up as: http://pastebin.com/4yNZxQKe and the utility class as http://pastebin.com/FtXS8YVz. Rationale being I need exactly this functionality for a geonode process (the one in the utility class) but not the wfs output format's specific concerns, and I would better avoid just copying and pasting? Generally speaking it seems ok, besides the bit that exposes a static method out of the utility writer (I think it's easy to make the method non static as you create the utility objects a few lines later). However I would like to look at it a bit closer, as I'm still half asleep :-) Can you open a jira and attach the patch there? Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] ShapeZipOutputFormat refactoring [Re: IOUtils.zipDirectory issue]
Can you open a jira and attach the patch there? sure. First thing when I get up (as I didn't got bed yet and am right about to :) Cheers, Gabriel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] Hudson build is back to normal: geoserver-trunk-online #77
See http://hudson.opengeo.org/hudson/job/geoserver-trunk-online/77/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] Tutorial documentation patch
Hi I’m new to geoserver development and was just working through A Simple PlugIn tutorial. There were some version issues with the old documentation for 1.6.x I have raised issue *GEOS-3890* http://jira.codehaus.org/browse/GEOS-3890* * and attached an updated version in .rst for 2.0.x Cheers Paul -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Image pyramid improvements and tutorial
Interesting that the nightly build I used really didn't work. I'll try a more recent one and let you know how it goes. I understand the performance issue. I'll add internal tiling to the tiffs in place, do some tests with our other software that accesses it, and if everything checks out, I won't have to duplicate the dataset. As this is a static dataset, I wasn't too worried about performance-- once I have the cache populated, I never have to populate it again, but that may be short-sighted if I end up combining the aerials imagery with other overlays that do change sometime down the road. Thanks again, Steve Stephen Mather, GIS Manager Cleveland Metroparks 4101 Fulton Pkwy Cleveland, OH 44144 s...@clevelandmetroparks.com Phone: (216) 635-3243 FAX: (216) 635-3286 -Original Message- From: Andrea Aime [mailto:aa...@opengeo.org] Sent: Thursday, April 01, 2010 2:32 AM To: s...@clevelandmetroparks.com Cc: 'Simone Giannecchini'; geoserver-devel@lists.sourceforge.net Subject: Re: [Geoserver-devel] Image pyramid improvements and tutorial Stephen V. Mather ha scritto: Hmm, the embarassment of naïve configuration... . :D Let me do some additional testing on my end. I assume then that you got the image pyramid plugin to work without a special version of GeoServer? Correct, just took a nightly build, pointed it at the cleaned up test directory (the first one that has tiles inside), after removing all shapefiles, all property files. However performance wise the result is not really usable, the reprojection is quite heavy Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] [jira] Created: (GEOS-3891) Population style doesn't work on trunk
Population style doesn't work on trunk
--
Key: GEOS-3891
URL: http://jira.codehaus.org/browse/GEOS-3891
Project: GeoServer
Issue Type: Bug
Reporter: David Winslow
Assignee: Andrea Aime
On my machine, any style with a TextSymbolizer anywhere in it fails to render
with the message:
{code}
...
Caused by: java.lang.ClassCastException: java.util.ArrayList cannot be cast to
org.geotools.styling.TextSymbolizer
at
org.geotools.renderer.lite.StreamingRenderer.processSymbolizers(StreamingRenderer.java:2056)
at
org.geotools.renderer.lite.StreamingRenderer.process(StreamingRenderer.java:1985)
at
org.geotools.renderer.lite.StreamingRenderer.drawOptimized(StreamingRenderer.java:1879)
...
{code}
I have ensured that I have the latest nightlies of GeoTools to build against.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] [jira] Created: (GEOS-3892) Discrete ColorMap ignores the final ColorMap entry
Discrete ColorMap ignores the final ColorMap entry -- Key: GEOS-3892 URL: http://jira.codehaus.org/browse/GEOS-3892 Project: GeoServer Issue Type: Bug Components: WMS Affects Versions: 2.0.1 Environment: Windows XP Reporter: Mike Pumphrey Assignee: Simone Giannecchini Priority: Minor Fix For: 2.0.2 Given the following SLD, one would expect three discrete colors in the resulting style. However, the last (highest) entry is always ignored, so any values higher than 200 are rendered as blank. ?xml version=1.0 encoding=ISO-8859-1? StyledLayerDescriptor version=1.0.0 xsi:schemaLocation=http://www.opengis.net/sld StyledLayerDescriptor.xsd xmlns=http://www.opengis.net/sld; xmlns:ogc=http://www.opengis.net/ogc; xmlns:xlink=http://www.w3.org/1999/xlink; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; NamedLayer UserStyle FeatureTypeStyle Rule RasterSymbolizer ColorMap type=intervals ColorMapEntry color=#008000 quantity=150 / ColorMapEntry color=#00 quantity=200 / ColorMapEntry color=#66 quantity=256 / /ColorMap /RasterSymbolizer /Rule /FeatureTypeStyle /UserStyle /NamedLayer /StyledLayerDescriptor -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] [jira] Created: (GEOS-3893) SLD doesn't validate when type parameter added to ColorMap
SLD doesn't validate when type parameter added to ColorMap Key: GEOS-3893 URL: http://jira.codehaus.org/browse/GEOS-3893 Project: GeoServer Issue Type: Bug Components: Validation Affects Versions: 2.0.1 Environment: Windows XP Reporter: Mike Pumphrey Assignee: Andrea Aime Priority: Minor Fix For: 2.0.2 There exists on this page: http://docs.geoserver.org/stable/en/user/styling/sld-reference/rastersymbolizer.html the ability to have a ColorMap with a parameter, viz: ColorMap type=intervals I can't be sure, but this looks like a Vendor Option. But even though the SLD validator ignores ordinary vendor options, validation fails when adding this parameter to the ColorMap: org.xml.sax.SAXParseException: cvc-complex-type.3.2.2: Attribute 'type' is not allowed to appear in element 'ColorMap'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] [jira] Created: (GEOS-3894) error when trying to open to a particular coveragestore from the layers dialogue
error when trying to open to a particular coveragestore from the layers dialogue Key: GEOS-3894 URL: http://jira.codehaus.org/browse/GEOS-3894 Project: GeoServer Issue Type: Bug Affects Versions: 2.0.0 Environment: unknown Reporter: Tara Athan Assignee: Andrea Aime Priority: Minor Attachments: jira.txt noticed this while running a metadata extraction with the rest interface, the GET for coverages from a particular coveragestore yielded an empty xml document the coverage store exists, and its configuration form can be opened from the stores dialogue, but not the layers dialogue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
