Re: [Geoserver-devel] Creating a new feature type and FeatureTypeInfo limitations
Yup it is definitely a limitation that will need to be addressed. Although I don't think it is that outlandish for a first cut to just default column types to string with some preset length, and refine from there. On 3/18/10 12:42 PM, Andrea Aime wrote: Hi, I was looking into the changes necessary to support the creation of a new feature type via REST and found some strong limitations in AttributeTypeInfo that do not allow even a partial implementation. The idea was that we could POST a feature type description to a datastore URL to create the new feature type. Now, look at the feature type description format here: http://docs.geoserver.org/stable/en/user/_downloads/featuretype_xml.txt Seeing anything missing in the attribute type descriptions? Like... the data type, for example? :-p In order to support a minimal type creation imho the attribute type description should contain: - the data type (as a java class) - the length restriction (important for any real world usage of string types) Very much welcomed would be also the number of decimals if we want to be able to create NUMBER(x,y) columns in a database. Oh hum... looks like a trunk only change to me? Well, in the meantime I'll play with a type creation GUI :-p Cheers Andrea -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- 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] Creating a new feature type and FeatureTypeInfo limitations
Right, this is done intentionally because we assume that an empty getAttributes() means derive them from the underlying feature type. The reason the persister uses getAttributes() and not attributes() is because if the attributes get stored on disk it then assumes the user has performed a manual override and then any ability to change the underlying feature type dynamically goes bye bye. That said in some cases we do want to output the derived attribute list, like for REST output. In my opinion I think we should probably just add a flag to XStreamPersister which will control this behaviour. By default leave the behaviour as is but for rest set the flag. We do this with various other things too. See AbstractCatalogResource.createXMLFormat(). -Justin On 3/18/10 2:24 PM, Andrea Aime wrote: Andrea Aime ha scritto: Oh hum... looks like a trunk only change to me? Well, in the meantime I'll play with a type creation GUI :-p Humm... tried to actually use the rest config instead but I'm getting stuck. So, I've added the necessary fields to AttributeTypeInfo and I was expecting to see them appear in the feature types xml descriptions. Unfortunately that's not happening. For feture types already configured, nothing changes, and for the new ones, there are no attributes at all in the output. For what I can see the issue is that the rest configuration is using FeatureTypeInfo.getAttributes(), that is, the stored ones, instead of calling to FeatureTypeInfo.attributes(). If I'm recalling things right the AttributeTypeInfo were used only to drive the schema overrides in terms of hiding/showing an attribute, so trying to use them to actually describe the attributes in the feature type is probably the wrong way to go? Or else, some rework is needed in all REST outputs/inputs to actually make them play the role of the attribute descriptors. Opinions? Cheers Andrea -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- 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-3865) Layer fails to reproject to EPSG:27700 from WGS84 when WFS request specifies version 1.0.0
Layer fails to reproject to EPSG:27700 from WGS84 when WFS request specifies version 1.0.0 -- Key: GEOS-3865 URL: http://jira.codehaus.org/browse/GEOS-3865 Project: GeoServer Issue Type: Bug Components: WFS Affects Versions: 2.0.0 Environment: Microsoft Windows Server 2003 R2 x64 Edition SP 2 Reporter: Keith Foster Assignee: Andrea Aime We have a layer that publishes point geometries from an Oracle spatial database. The data is stored in the database in WGS84 and the layer is configured to reproject native to declared into EPSG:27700 (British National Grid). When a WFS request is received specifying version 1.1.0 the reprojection works. When the request specifies version 1.0.0 however, the features are returned unprojected with WGS84 lat / lon values. -- 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] New functionality: creating new feature types with an sql query in jdbc data stores
Hi, during the NY OpenGeo code sprint last month we've designed and coded support for what we call virtual tables, that is, feature types that are defined via a straight, native sql query. If you cannot wait to see the code there is a patch attached to http://jira.codehaus.org/browse/GEOT-2123. Interaction wise, with the current state of the patch you can define virtual tables either via a factory parameter or with code. The factory parameter is a string in property file format, the definition of a virtual table can look like: myVirtTable=select a, b, c, the_geom from realtable where a 3 myVirtTable.pk=a,b myVirtTable.geom.the_geom=POINT,4326 The definition states that the myVirtTable is defined by the query select a, b, c, the_geom from realtable where a 3, that the fids are generated using the columns a and b (it does not mean it's writable, just allows for stable fids), and that the the_geom column is geometric, POINT type, and the native srid is 4326. You can add as many definitions as you want in the property file. Programmatically it looks like: VirtualTable vt = new VirtualTable(myVirtTable, select a, b, c, the_geom from realtable where a 3); vt.addGeometryMetadatata(the_geom, Point.class, 4326); vt.setPrimaryKeyColumns(Arrays.asList(a, b)); dataStore.addVirtualTable(vt); Internally the code takes the SQL provided and builds queries that use the SQL as a subquery in the FROM clause, something we verified all major databases support today. Something like: select the fields in the Query from (your sql) where filters in the Query GeoServer wise I'm not too happy with the usage of the factory parameter and I was considering dropping it. Since we are already planning to have a UI to add new feature types, this would fit squarely as a variant to it, instead of creating a new table you give me a query and some metadata. So it would end up in the create new layer workflow. The query and the metadata would be stored in the FeatureTypeInfo metadata map, and we'd need a callback from ResourcePool that allows for configuration of the data store: grab all the feature type info connected to that datastore, scan for view definitions, register them as the datastore is being created. Add and drop dynamically as these are created, removed or updated by the user. Soo... how does it sound? And also, where will it ring? Trunk only? GS wise it would be a nice way to push users to upgrade once GS 2.1 is out. 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-3866) Query's typeName attribute not correctly parsed when using XML POST
Query's typeName attribute not correctly parsed when using XML POST
---
Key: GEOS-3866
URL: http://jira.codehaus.org/browse/GEOS-3866
Project: GeoServer
Issue Type: Bug
Components: WFS
Affects Versions: 2.0.1
Environment: WindowsXP, java 1.6.10_7; Linux/Debian (Lenny), java
1.6.0_12.
Reporter: Daniele Benegiamo
Assignee: Andrea Aime
As stated from WFS 1.1.0 specifications, Query's typeName attribute should be
a comma separated list of feature type names to query (with optional alias
assignments). Unfortunately it's value is not parsed correctly when using XML
POST method, it fails when:
- multiple type names are used (as topp:tasmania_roads,topp:tasmania_cities),
it don't split the string (i.e., it read topp as namespace and
tasmania_roads,topp:tasmania_cities as feature type name); *this make
impossible to perform join queries*;
- aliases are used (as topp:tasmania_roads=x, as before it reads topp as
namespace and tasmania_roads=x as type name);
- if strict CITE compliance is enabled, type names with underscores are not
matched.
Example that fails, using multiple type names:
{code:xml}
wfs:GetFeature service=WFS version=1.1.0
xmlns:topp=http://www.openplans.org/topp;
xmlns:wfs=http://www.opengis.net/wfs;
xmlns:ogc=http://www.opengis.net/ogc;
xmlns:gml=http://www.opengis.net/gml;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.opengis.net/wfs
http://schemas.opengis.net/wfs/1.1.0/wfs.xsd;
wfs:Query typeName=topp:tasmania_roads,topp:tasmania_cities
ogc:Filter
ogc:BBOX
ogc:PropertyNamethe_geom/ogc:PropertyName
gml:Envelope srsName=http://www.opengis.net/gml/srs/epsg.xml#4326;
gml:lowerCorner147.17973 -43.06686/gml:lowerCorner
gml:upperCorner147.40877 -42.68815/gml:upperCorner
/gml:Envelope
/ogc:BBOX
/ogc:Filter
/wfs:Query
/wfs:GetFeature
{code}
The same using GET request works:
{code}
http://localhost:8080/geoserver/wfs?service=WFSrequest=GetFeatureversion=1.1.0typeName=topp:tasmania_roads,topp:tasmania_citiesBBOX=147.17973,-43.06686,147.40877,-42.68815,EPSG:4326
{code}
But in this later case setting an alias (escaping the '=' symbol with '%3D')
fails (e.g. tasmania_roads%3Da is read as tasmania_roads=a).
--
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
Re: [Geoserver-devel] New functionality: creating new feature types with an sql query in jdbc data stores
On Fri, Mar 19, 2010 at 10:22 AM, Andrea Aime aa...@opengeo.org wrote: [... lots of cool stuff ...] This sounds really cool Andrea, I'll see if I can test it out next week before marking kicks in. I really wish I had known that the Java tribe was going to the NY Sprint as I'd have come over, however all the publicity gave the impression it was a C tribe event. Ian -- Ian Turton -- 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] New functionality: creating new feature types with an sql query in jdbc data stores
Ian Turton ha scritto: On Fri, Mar 19, 2010 at 10:22 AM, Andrea Aime aa...@opengeo.org wrote: [... lots of cool stuff ...] This sounds really cool Andrea, I'll see if I can test it out next week before marking kicks in. I really wish I had known that the Java tribe was going to the NY Sprint as I'd have come over, however all the publicity gave the impression it was a C tribe event. OpenGeo had the annual retreat a few days later than the sprint, so me, Justin and Gabriel decided to join and work a bit along with them. This functionality was actually coded during the retreat, where we had a few more hours to spend coding cool stuff. 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-3867) Bug in display of image pyramid imagery
Bug in display of image pyramid imagery --- Key: GEOS-3867 URL: http://jira.codehaus.org/browse/GEOS-3867 Project: GeoServer Issue Type: Bug Environment: Windows 2003 Server R2, Standard Edition SP2 GeoServer 2.0.x-2010-03-03 GeoServer 2.0.2-SNAPSHOT-pyramid-plugin Reporter: Stephen Mather Assignee: Andrea Aime Some of the tiles in an image pyramid data store never render at their full resolution for a given zoom level, but at a reduced resolution. If I load ~16 tiles vs. loading e.g. 40+ tiles the places where this happens shifts, i.e. tiles that were a problem before stop being a problem, while other tiles exhibit the same behavior. I have public data that demonstrates this effect, but it is 80MB plus zipped. -- 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
Re: [Geoserver-devel] Image pyramid improvements and tutorial
Hi Andrea, I've submitted a bug report on JIRA. I have a ~80MB example zip. How would you prefer I send that to you? 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, March 18, 2010 11:22 AM To: Stephen Mather Cc: geoserver-devel@lists.sourceforge.net Subject: Re: [Geoserver-devel] Image pyramid improvements and tutorial Stephen Mather ha scritto: Hi Andrea, I've been working on giving it a spin with our own data. The tutorial is excellent. Easy to read and follow. I'm currently testing it on a Windows 2003 server with nightly build geoserver-2.0.x-2010-03-03-bin.zip, and geoserver-2.0.2-SNAPSHOT-pyramid-plugin.zip The test I've been doing is with 0.5ft (0.15m) color orthophotos that sum to about 150GB as TIFFs. They are currently tiled as 5000x4000 images. I've retiled them with gdal_retile as 2048x2048 images with overviews with the following command: gdal_retile -v -s_srs EPSG:102722 -levels 5 -ps 2048 2048 -targetdir test3 --optfile tilelist.txt I'm currently working on a subset of the data for testing. Checking all the tiles generated from gdal_retile, they all look fine in an image viewer, and check out (with a spot check) with gdalinfo. When I load them in GeoServer, I get a strange effect. Some of the tiles never render at their full resolution for a given zoom level, but at a reduced resolution. If I load ~16 tiles vs. loading e.g. 40+ tiles the places where this happens shifts, i.e. tiles that were a problem before stop being a problem, while other tiles exhibit the same behavior. Does this make sense, is this an effect you've seen, and would images and log files be helpful? I actually never seen this effect. Can you open a report on Jira? To be effective we should also be able to reproduce the problem. Can you generate it with any freely available imagery set? 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] Image pyramid improvements and tutorial
Qcuik questions: - are you adding a reprojection in the mix while you are doing this tests? - are all your granules of the same resolution? Simone. --- Ing. Simone Giannecchini GeoSolutions S.A.S. Founder - Software Engineer Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob:+39 333 8128928 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/simonegiannecchini http://twitter.com/simogeo --- On Tue, Mar 16, 2010 at 1:13 PM, Stephen Mather s...@clevelandmetroparks.com wrote: Hi Andrea, I've been working on giving it a spin with our own data. The tutorial is excellent. Easy to read and follow. I'm currently testing it on a Windows 2003 server with nightly build geoserver-2.0.x-2010-03-03-bin.zip, and geoserver-2.0.2-SNAPSHOT-pyramid-plugin.zip The test I've been doing is with 0.5ft (0.15m) color orthophotos that sum to about 150GB as TIFFs. They are currently tiled as 5000x4000 images. I've retiled them with gdal_retile as 2048x2048 images with overviews with the following command: gdal_retile -v -s_srs EPSG:102722 -levels 5 -ps 2048 2048 -targetdir test3 --optfile tilelist.txt I'm currently working on a subset of the data for testing. Checking all the tiles generated from gdal_retile, they all look fine in an image viewer, and check out (with a spot check) with gdalinfo. When I load them in GeoServer, I get a strange effect. Some of the tiles never render at their full resolution for a given zoom level, but at a reduced resolution. If I load ~16 tiles vs. loading e.g. 40+ tiles the places where this happens shifts, i.e. tiles that were a problem before stop being a problem, while other tiles exhibit the same behavior. Does this make sense, is this an effect you've seen, and would images and log files be helpful? Thanks, Steve Andrea Aime-4 wrote: Hi all, lately I've been working, under OpenGeo request, to improve the situation vs image pyramids, in particular, making it easier to configure a file based one. ... Is anyone interested to give the tutorial a spin, a review? Is there anything missing or that could be done better? Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- View this message in context: http://old.nabble.com/Image-pyramid-improvements-and-tutorial-tp27608654p27910740.html Sent from the GeoServer - Dev mailing list archive at Nabble.com. -- 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 mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Image pyramid improvements and tutorial
Qcuik questions: - are you adding a reprojection in the mix while you are doing this tests? I have tried it both with and without reprojection, to the same effect. - are all your granules of the same resolution? Yes, they are all 0.15m pixels in 5000x4000 images. I have tried both leaving the existing 0 level images at 5000x4000 (-pyramidOnly) and retiling to 2048x2048, both with the same result. Steve On Tue, Mar 16, 2010 at 1:13 PM, Stephen Mather s...@clevelandmetroparks.com wrote: Hi Andrea, I've been working on giving it a spin with our own data. The tutorial is excellent. Easy to read and follow. I'm currently testing it on a Windows 2003 server with nightly build geoserver-2.0.x-2010-03-03-bin.zip, and geoserver-2.0.2-SNAPSHOT-pyramid-plugin.zip The test I've been doing is with 0.5ft (0.15m) color orthophotos that sum to about 150GB as TIFFs. They are currently tiled as 5000x4000 images. I've retiled them with gdal_retile as 2048x2048 images with overviews with the following command: gdal_retile -v -s_srs EPSG:102722 -levels 5 -ps 2048 2048 -targetdir test3 --optfile tilelist.txt I'm currently working on a subset of the data for testing. Checking all the tiles generated from gdal_retile, they all look fine in an image viewer, and check out (with a spot check) with gdalinfo. When I load them in GeoServer, I get a strange effect. Some of the tiles never render at their full resolution for a given zoom level, but at a reduced resolution. If I load ~16 tiles vs. loading e.g. 40+ tiles the places where this happens shifts, i.e. tiles that were a problem before stop being a problem, while other tiles exhibit the same behavior. Does this make sense, is this an effect you've seen, and would images and log files be helpful? Thanks, Steve Andrea Aime-4 wrote: Hi all, lately I've been working, under OpenGeo request, to improve the situation vs image pyramids, in particular, making it easier to configure a file based one. ... Is anyone interested to give the tutorial a spin, a review? Is there anything missing or that could be done better? Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. - - SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- View this message in context: http://old.nabble.com/Image-pyramid-improvements-and-tutorial-tp27608654p279 10740.html Sent from the GeoServer - Dev mailing list archive at Nabble.com. -- 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 mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
