Re: [Geoserver-users] GeoTIFFs verus JP2
Le vendredi 22 novembre 2013 19:18:56, Rahkonen Jukka a écrit : Hi, I think that the reason is that is is hard/impossible to make an optimal deflate compressed tiff when gdal_merge goes through the circle open file - add data - close file. There are other alternatives to test: - You can use a non-optimal deflate compressed tiff as a temporary file - is is lossless and the final result will be identical. - Use gdalbuildvrt for making an interim .VRT file and convert that to final product instead of using gdal_merge.py. Perhaps GDAL can make an optimal deflate compressed image from the VRT file with one run. A hint: If you play with big datasets and deflate compressed images GDAL sometimes does not guess when it should jump into BigTIFF. Give the -co bigtiff=yes parameter manually if you feel that it could be needed. If Even is still sneaking here he can say if the behaviour you see with gdal_merge.py is expected or a bug. Otherwise you can ask it from gdal-dev mailing list. I'm not sure which gdal_merge behaviour Jukka is refering too, but indeed it might not be the appropriate tool to mosaic stuff into a compressed geotiff due to the way it operates (it can have to do uncompression / recompression cycles that will waste space in the geotiff). gdalbuildvrt to do the mosaicing (without a disk footprint of only a few bytes) followed by gdal_translate to compress will lead to the optimal file size. -Jukka- Jonathan Moules wrote: On 21 November 2013 21:23, Rahkonen Jukka jukka.rahko...@mmmtike.fimailto:jukka.rahko...@mmmtike.fi wrote: I would try if it makes difference to save result from gdal_merge first into uncompressed tiff and compress it with deflate in a separate run. Yep, that worked. Although that's unfeasible for the full dataset; I don't have enough diskspace for an uncompressed version. Also, doing that (deflate, level 9), the tiled version was about 15% smaller than the untiled version. Thanks! Jonathan Jukka Rahkonen Jonathan Moulesmailto:jonathanmou...@warwickshire.gov.uk wrote: It is not completely surprising. If there are no repeateable patterns in the uncompressed stream, deflate can result in (a bit) larger files. You might want to try with -co INTERLEAVE=BAND added to see if it improves things. But generally DEFLATE is not appropriate for aerial imagery. The bit larger files are typically about double the size of the uncompressed one! I know deflate isn't as well suited, but I'm experimenting with a whole bunch of different settings to see what sticks. == I'm now trying to get the four band into GeoServer (regular GeoTIFF), but it's not having it. I've created it the same way as the 3 band: gdal_merge -q -o rgbi.tif -of GTiff -co TILED=YES -co BIGTIFF=YES -co COMPRESS=JPEG -co JPEG_QUALITY=25 -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 --optfile tiff_list.txt (low compression for testing). No pyramids yet. The first thing I notice is that the 4 band is *smaller* (118MB) than the 3 band (164MB). The gdalinfo for the four band: Driver: GTiff/GeoTIFF Files: rgbi.tif Size is 8000, 24000 Coordinate System is: PROJCS[OSGB 1936 / British National Grid, [brevity removed] Origin = (419000.000,24.000) Pixel Size = (0.125,-0.125) Metadata: AREA_OR_POINT=Area Image Structure Metadata: COMPRESSION=JPEG INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( 419000.000, 24.000) ( 1d43'22.27W, 52d 3'27.49N) Lower Left ( 419000.000, 237000.000) ( 1d43'22.87W, 52d 1'50.38N) Upper Right ( 42.000, 24.000) ( 1d42'29.76W, 52d 3'27.37N) Lower Right ( 42.000, 237000.000) ( 1d42'30.39W, 52d 1'50.26N) Center ( 419500.000, 238500.000) ( 1d42'56.32W, 52d 2'38.88N) Band 1 Block=512x512 Type=Byte, ColorInterp=Red Mask Flags: PER_DATASET ALPHA Band 2 Block=512x512 Type=Byte, ColorInterp=Green Mask Flags: PER_DATASET ALPHA Band 3 Block=512x512 Type=Byte, ColorInterp=Blue Mask Flags: PER_DATASET ALPHA Band 4 Block=512x512 Type=Byte, ColorInterp=Alpha The GeoServer logs contain an error (WMS GetMap request): 2013-11-20 17:56:07,498 ERROR [org.geoserver.ows] - java.lang.RuntimeException: javax.imageio.IIOException: Unsupported Image Type at com.sun.media.jai.imageioimpl.ImageReadOpImage.computeTile(ImageReadOpImag e.java:706) at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java :904) at javax.media.jai.OpImage.getTile(OpImage.java:1129) Caused by: javax.imageio.IIOException: Unsupported Image Type at com.sun.imageio.plugins.jpeg.JPEGImageReader.readInternal(Unknown Source) at com.sun.imageio.plugins.jpeg.JPEGImageReader.read(Unknown Source) at it.geosolutions.imageioimpl.plugins.tiff.TIFFJPEGDecompressor.decodeRaw(TI FFJPEGDecompressor.java:278) Ideally I'm looking to have one source
Re: [Geoserver-users] GeoTIFFs verus JP2
Le mercredi 20 novembre 2013 18:21:06, Jonathan Moules a écrit : Hi List, One thing I'm noticing with PHOTOMETRIC=YCBCR - I'm losing a lot of sharpness. In fact, a 50% without YCBCR looks better than a 85% that also has YCBCR enabled. This is very noticeable at the native resolution, but once you're about double it or further, it's effectively invisible. YCbCr comes with a oversampling by a factor of 2 of the Cb and Cr channels, hence the extra compression and quality loss. Although than this oversampling is done because the human eye is less sensible to chromatic than luminance. On the other hand, the YCBCR is about 25% the size of a equivalently compressed JPEG. I guess I'm going to have to choose which way to go. I've also been testing a lot of other variables and for some reason DEFLATE compression seems to make the file *larger* in all circumstances. It doesn't matter what the Z level is (even 9), or predictor, in all instances the resultant file is larger than an uncompressed version. That's with four band data. Anyone know why? It is not completely surprising. If there are no repeateable patterns in the uncompressed stream, deflate can result in (a bit) larger files. You might want to try with -co INTERLEAVE=BAND added to see if it improves things. But generally DEFLATE is not appropriate for aerial imagery. Cheers, Jonathan On 12 November 2013 14:24, Jonathan Moules jonathanmou...@warwickshire.gov.uk wrote: HI All, Many thanks for the all the responses. Interesting discussion; I've learnt a lot. I think my next step is to do some testing; I've not tried the four band - RGBI imagery yet. When I do I'll post back here with whatever seems to work best. Cheers, Jonathan On 12 November 2013 13:45, Even Rouault even.rouault@mines- paris.orgwrote: Selon Andrea Aime andrea.a...@geo-solutions.it: On Tue, Nov 12, 2013 at 12:45 PM, Simone Giannecchini simone.giannecch...@geo-solutions.it wrote: Will the PHOTOMETRIC= YCBCR work with a four band RGBI? It should not. Actually... JPEG itself is not defined on 4 bands images as far as I know? Maybe GDAL is dropping the 4th band during the JPEG compression? The YCbCR JPEG profile of TIFF is indeed limited to 3 bands. So if you pass a 4 band image, gdal_translate should refuse to process it. You can JPEG compress a 4 band image, but it will use a JPEG codestream for each band independantly, so the resulting size will be bigger. A possible option would be to generate 2 GeoTIFFs for each input file : one YCbCR JPEG compressed with the RGB components, and one JPEG compressed with the I component. But that might complicate the overall workflow. Even Cheers Andrea -- == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clk trk ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users -- Geospatial professional services http://even.rouault.free.fr/services.html -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] GeoTIFFs verus JP2
Selon Andrea Aime andrea.a...@geo-solutions.it: On Tue, Nov 12, 2013 at 12:45 PM, Simone Giannecchini simone.giannecch...@geo-solutions.it wrote: Will the PHOTOMETRIC= YCBCR work with a four band RGBI? It should not. Actually... JPEG itself is not defined on 4 bands images as far as I know? Maybe GDAL is dropping the 4th band during the JPEG compression? The YCbCR JPEG profile of TIFF is indeed limited to 3 bands. So if you pass a 4 band image, gdal_translate should refuse to process it. You can JPEG compress a 4 band image, but it will use a JPEG codestream for each band independantly, so the resulting size will be bigger. A possible option would be to generate 2 GeoTIFFs for each input file : one YCbCR JPEG compressed with the RGB components, and one JPEG compressed with the I component. But that might complicate the overall workflow. Even Cheers Andrea -- == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] WFS MaxFeatures count - can a client know?
Selon Rahkonen Jukka jukka.rahko...@mmmtike.fi: Hi, The count of features received with resulttype=results should match the count in resulttype=hits. That also makes most sense for me because that way the client can make a test and re-think and adjust the request before sending the real GetFeature. However, often it would be useful to know also the total count of features in the service but that is missing from the WFS standard. In practice it means that for example GDAL when it reads the layer summary with ogrinfo and -so switch http://www.gdal.org/ogrinfo.html through WFS driver http://www.gdal.org/ogr/drv_wfs.html the utility actually reads the whole feature type. Or tries to read, it may hit the server side maxfeatures naturally. Actually, this is not the exact reason. For the summary of the feature count, the OGR WFS driver will issue a resulttype=hits request (but I now realize that it might be lower than the total number of features in the layer, but as there's no way to know it, that's OK). The reason for it to issue a full feature download is to get the layer extent, due to the fact that the advertized one in GetCapabilities is sometimes not reliable. I might end up changing this non-friendly network bandwith behaviour some day... Even -Jukka- Jonathan Moules Hi Jukka, I see what the difference is after some testing. Using the exact same URL but only changing the WFS version: http://wppgeog3/geoserver/ows?service=wfsversion=2.0.0request=getfeaturetypename=Public_Data_DB:OS_ADDPOINT_WSHIREresulttype=hits WFS 1.0.0 - 0 (wrong) WFS 1.1.0 - 7500 (correct) WFS 2.0.0 - 0 (wrong) Looking in the spec, 1.0.0 doesn't seem to have resulttype (but Geoserver tries anyway). It's in both 1.1.0 and 2.0.0 though. So looks like a bug, reported as http://jira.codehaus.org/browse/GEOS-6145 = One thought - shouldn't resulttype=hits return the *actual* number of features that satisfy the user-query, not the number that satisfy the query after GeoServer has added the maxfeatures to it? So if the limit is 7500, and my database contains 10,000,000, shouldn't it return 10,000,000? The specs don't say clearly one way of the other which it should be. Cheers, Jonathan On 8 November 2013 15:13, Rahkonen Jukka jukka.rahko...@mmmtike.fimailto:jukka.rahko...@mmmtike.fi wrote: Hi Jonathan, This is another WFS but like this it should work Client side maxfeatures=10, numberOfFeatures=10 http://hip.latuviitta.org/cgi-bin/tinyows?service=wfsversion=1.1.0maxfeatures=10request=getfeaturetypename=lv:mtk_tos_viivaresulttype=hits No client side maxfeatures, numberOfFeatures=10, probably the server side limit http://hip.latuviitta.org/cgi-bin/tinyows?service=wfsversion=1.1.0maxrequest=getfeaturetypename=lv:mtk_tos_viivaresulttype=hits -Jukka Rahkonen- Jonathan Moules Hi Jukka, Ok. It just seems like the sort of thing that would be very important for the client to know so it can tell the user Server returned 1000 features but the server will only ever return 1000 features at a time so this may not be the entire dataset. Testing your suggestion, whenever I do that I always get back the exact same: wfs:FeatureCollection xmlns:OS_Rasters=http://www.warwickshire.gov.uk/os_rasters; xmlns:ogc=http://www.opengis.net/ogc; xmlns:Secure_Community=http://www.warwickshire.gov.uk/Secure_Community; xmlns:OS_Vector=http://www.warwickshire.gov.uk/os_vector; xmlns:wfs=http://www.opengis.net/wfs; xmlns:ows=http://www.opengis.net/ows; xmlns:xlink=http://www.w3.org/1999/xlink; xmlns:Misc_Rasters=http://www.warwickshire.gov.uk/misc_rasters; xmlns:gml=http://www.opengis.net/gml; xmlns:Public_Data_DB=http://www.warwickshire.gov.uk/public_data_db; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; numberOfFeatures=0 timeStamp=2013-11-08T14:55:55.783Z xsi:schemaLocation=http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd/ Note it's claimed 0 features. Despite the fact the request does return 7500 features (maximum). A bug? I've not used that before. Cheers, Jonathan On 8 November 2013 14:34, Rahkonen Jukka jukka.rahko...@mmmtike.fimailto:jukka.rahko...@mmmtike.fi wrote: Hi, Not directly as far as I know, but by sending GetFeature without filters and with resulttype=hits it should be possible to do a good guess. -Jukka Rahkonen- Jonathan Moules wrote: Hi List, Relatively simple question, is it possible to a client to discover what the maximum number of results are that the GeoServer will return to a WFS request if the user has set Maximum number of features? It doesn't seem to be specified in the GetCapabilities explicitly. Closest I can see is the WFS 2.0 ows:Constraint name=CountDefault Does 1.0 have any way to find it out? Thanks, Jonathan This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly.
Re: [Geoserver-users] JVM goes up in smoke
Le lundi 18 mars 2013 10:26:44, Andrea Aime a écrit : On Mon, Mar 18, 2013 at 7:34 AM, cmaul christian.m...@dse.vic.gov.auwrote: Because the tiles are cut from ecw there are a lot of components involved. Where could I find an indicator of what it is that's making the JVM collapse? The ECW SDK can consume a lot of RAM (and there was a bug in old SDK 3.3 where in some configurations, the 1/4 RAM threshold was not respected). You should look at the ECW_CACHE_MAXMEM configuration option / environement variable documented in http://gdal.org/frmt_ecw.html Welcome to the wondering world of native code integration... a minor glitch in GDAL or the ECW is enough to take down the entire JVM, there is no protection against SEGFAULT errors in native code. That said, I'm not sure how to help... maybe it's the specific ECW version, I believe GDAL is supposed to be built against version 3.x... but I also may be quite off the mark. On the bright side GDAL is working on a plan to have these readers work in a separate process, in order to proctect itself from such catastrophic failures. But I don't know if/when that will be available, you might want to check on the GDAL mailing list. GDAL 1.10 to be released in a couple of weeks : http://gdal.org/gdal_api_proxy.html Cheers Andre -- Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] 'Fuzzy' image with RPFTOC Raster Data Source
Le jeudi 17 janvier 2013 03:01:34, mortac8 a écrit : I am trying to display some RPF (Raster) data in GeoServer. If I use the RPFTOC, the performance is good but my image quality is quite poor. Can one of the experts please comment on what is happening and what I need to look into to fix it? I will attach a screenshot showing an ImageMosaic on the left and the RPFTOC version of the same data on the right. Try setting the RPFTOC_FORCE_RGBA environmenet variable to TRUE. See http://gdal.org/frmt_various.html#RPFTOC http://i.imgur.com/NZkvt.jpg Thanks so much! Ashley -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Fuzzy-image-with-RPFTOC-Raster-Data-So urce-tp5027999.html Sent from the GeoServer - User mailing list archive at Nabble.com. --- --- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] Generate spatial index for shapefile
Yes, the format is the same, but the .qix files generated by GeoServer should be smaller and perform somewhat better (we have a few heuristics to get a small but effective index, avoid isolated laves with single records and the like). A recent version of uDig will generate the same .qix file as GeoServer though Hi Andrea, Your remark aroused my curiosity. I have indeed identified a small addition in the geotools port of shapelib's shptree.c that must explain that optimization and adapted it to shptree.c. I've not verified however if the geotools .qix and shapelib .qix are now identical, but I've seen that the new code path is triggered in some conditions. See http://trac.osgeo.org/gdal/ticket/4472 for the patch. Best regards, Even -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
[Geoserver-users] Interpretation of STARTINDEX in WFS : GeoServer and MapServer disagree
Hi, I read with interest http://geo-solutions.blogspot.com/2011/12/wfs-for-masses-adding-support-for.html and decided to play with GeoServer 2.1.3 and its paging support a bit, with the OGR WFS driver. I've tested on the samples (tiger:poi layer) and discovered that GeoServer takes as convention that STARTINDEX=0 is the first feature. The issue is that MapServer 6 took the convention that STARTINDEX=1 is the first feature, and this is the convention I used to write the OGR WFS driver. I decided to read again the WFS 2.0 spec PDF and unfortunately I find it quite ambiguous in the spec part, but in the B.8.4.7 Example 7 section, it reads : Find the 5th highest mountain in the region around the Himalayas. http://www.someserver.com/wfs.cgi? SERVICE=WFS VERSION=2.0.0 REQUEST=GetFeature TYPENAMES=Mountains BBOX=27.6669,86.4800,28.2709,87.2120 SORTBY=Elevation DESC STARTINDEX=5 COUNT=1 which would confirm the interpretation of STARTINDEX=1 for the first feature, and STARTINDEX=0. Any thoughts ? Best regards, Even -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] Interpretation of STARTINDEX in WFS : GeoServer and MapServer disagree
Selon Bart van den Eijnden bart...@osgis.nl: Hi Even, but if you look at the schema [1], a value of 0 makes more sense to me (default value is 0 and not 1): xsd:attribute name=startIndex type=xsd:nonNegativeInteger default=0/ [1] http://schemas.opengis.net/wfs/2.0/wfs.xsd Yes, I agree, but the example in the PDF contradicts that, no ? It is a shame that there is no clear text saying somehow Index 0 means first feature. Who could confirm the correct interpretation ? Best regards, Bart -- Bart van den Eijnden OSGIS - http://osgis.nl On Jan 4, 2012, at 2:57 PM, Even Rouault wrote: Hi, I read with interest http://geo-solutions.blogspot.com/2011/12/wfs-for-masses-adding-support-for.html and decided to play with GeoServer 2.1.3 and its paging support a bit, with the OGR WFS driver. I've tested on the samples (tiger:poi layer) and discovered that GeoServer takes as convention that STARTINDEX=0 is the first feature. The issue is that MapServer 6 took the convention that STARTINDEX=1 is the first feature, and this is the convention I used to write the OGR WFS driver. I decided to read again the WFS 2.0 spec PDF and unfortunately I find it quite ambiguous in the spec part, but in the B.8.4.7 Example 7 section, it reads : Find the 5th highest mountain in the region around the Himalayas. http://www.someserver.com/wfs.cgi? SERVICE=WFS VERSION=2.0.0 REQUEST=GetFeature TYPENAMES=Mountains BBOX=27.6669,86.4800,28.2709,87.2120 SORTBY=Elevation DESC STARTINDEX=5 COUNT=1 which would confirm the interpretation of STARTINDEX=1 for the first feature, and STARTINDEX=0. Any thoughts ? Best regards, Even -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] Interpretation of STARTINDEX in WFS : GeoServer and MapServer disagree
Selon Bart van den Eijnden bart...@osgis.nl: Wrt count, I can see there is already a change request by Peter (187) in the OGC portal: Update Table 5 to indicate that there is no default value. Also is clause 7.6.3.5 correct the sentence fragment ... presented to the client subject to any server a configured limits. to read ... presented to the client subject to any server configured limits.. (i.e. Remove the 'a' before the work configured). Which leads me to another change request for startIndex (159): Update the standard and the schemas to make sure that the default value for the startIndex parameter is 1 everywhere. So all should be clear now ;-) Yes, very clear now. I've filed a GeoServer ticket : http://jira.codehaus.org/browse/GEOS-4920 Best regards, Bart -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] Interpretation of STARTINDEX in WFS : GeoServer and MapServer disagree
Peter, What about https://portal.opengeospatial.org/files/?artifact_id=44921 where you write the contrary, if I understand well... I'm afraid I'm lost. Bart, I think it should be 0. Table 5 is in error. If you look for all instances of startIndex in the spec., it is zero everywhere except table 5. I'll post a change request to fix it. Ciao. On 01/04/2012 09:20 AM, Bart van den Eijnden wrote: The editor of the WFS spec (Peter Vretanos) should be able to clarify. Peter, should startIndex start at 0 or at 1? See also the discussion below. TIA. Best regards, Bart -- Bart van den Eijnden OSGIS - http://osgis.nl On Jan 4, 2012, at 3:14 PM, Even Rouault wrote: Selon Bart van den Eijnden bart...@osgis.nl mailto:bart...@osgis.nl: Hi Even, but if you look at the schema [1], a value of 0 makes more sense to me (default value is 0 and not 1): xsd:attribute name=startIndex type=xsd:nonNegativeInteger default=0/ [1] http://schemas.opengis.net/wfs/2.0/wfs.xsd Yes, I agree, but the example in the PDF contradicts that, no ? It is a shame that there is no clear text saying somehow Index 0 means first feature. Who could confirm the correct interpretation ? Best regards, Bart -- Bart van den Eijnden OSGIS - http://osgis.nl On Jan 4, 2012, at 2:57 PM, Even Rouault wrote: Hi, I read with interest http://geo-solutions.blogspot.com/2011/12/wfs-for-masses-adding-support-for.html and decided to play with GeoServer 2.1.3 and its paging support a bit, with the OGR WFS driver. I've tested on the samples (tiger:poi layer) and discovered that GeoServer takes as convention that STARTINDEX=0 is the first feature. The issue is that MapServer 6 took the convention that STARTINDEX=1 is the first feature, and this is the convention I used to write the OGR WFS driver. I decided to read again the WFS 2.0 spec PDF and unfortunately I find it quite ambiguous in the spec part, but in the B.8.4.7 Example 7 section, it reads : Find the 5th highest mountain in the region around the Himalayas. http://www.someserver.com/wfs.cgi? SERVICE=WFS VERSION=2.0.0 REQUEST=GetFeature TYPENAMES=Mountains BBOX=27.6669,86.4800,28.2709,87.2120 SORTBY=Elevation DESC STARTINDEX=5 COUNT=1 which would confirm the interpretation of STARTINDEX=1 for the first feature, and STARTINDEX=0. Any thoughts ? Best regards, Even -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users -- Panagiotis (Peter) A. Vretanos CubeWerx Inc. Big Kahuna (Senior Database Developer) http://www.cubewerx.com Tel. 416-701-1985 Fax. 416-701-9870pvret...@cubewerx.com Engineers: DO NOT move coffee machine; it will change settings. Physicists: DO NOT observe coffee machine; it will change quantum states. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
