[gdal-dev] FWD: OGC seeks comment on revised GML in JPEG 2000
Hi, I think this may be of interested within the GDAL community: http://www.opengeospatial.org/pressroom/pressreleases/1965 Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] FWD: OGC seeks comment on revised GML in JPEG 2000
Mateusz Łoskot mateusz at loskot.net writes: Hi, I think this may be of interested within the GDAL community: http://www.opengeospatial.org/pressroom/pressreleases/1965 Hi, First time ever I tried to send feedback to OGC. Let's see if my mail went through. I commented two issues: 1. It looks like OGC has defined that origin in georeferencing means the centre of pixel in change number 6: Clarification of the use of CRS and Rectified grid coverage / image georeference with origin point (at pixel center). Is this interpretation right and could it be expressed in some fool proof way, like Origin of the RectifiedGrid is placed at the centre point of the corner pixel 2. Throughout the paper srsNames are given in two different ways. - srsName=http://www.opengis.net/def/crs/EPSG/0/4326; - srsName=urn:ogc:def:crs:EPSG::4326 In one example there is even this. - srsName=EPSG:4326 I believe that it means that both http and urn versions can be used but there was not enough room in the 91 pages long document to tell that. Perhaps the meaning is to be explicit and therefore there is a reference to another document with number OGC 07-092r3 http://portal.opengeospatial.org/files/?artifact_id=30575 However, reading OGC 07-092r3 does not help, that document does not mention at all that srsName=http://www.opengis.net/def/crs/EPSG/0/4326; could be used but it knows only the urn syntax. The same thing in with units of measures. There is a table 3 URIs for units-of-measure that gives examples of how to refer to UoM and they are like - http://www.opengis.net/def/uom/OGC/1.0/metre or - http://www.opengis.net/def/uom/EPSG/6.3/9001 But in XML examples UoMs are expressed mostly as - uom=urn:ogc:def:uom:EPSG::9001 There seems to be also at least one copy-paste error in the examples: Envelope srsName=http://www.opengis.net/def/crs/EPSG/0/4326; axisLabels=Lat Long uomLabels=deg deg srsDimension=2 lowerCorner270379.500 3942462.000/lowerCorner upperCorner518842.500 3942462.000/upperCorner /Envelope -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] FWD: OGC seeks comment on revised GML in JPEG 2000
Hi, I'm also trying to read that - bp - too long document and I guess I should also read GMLCOV to make sense of it One thing among others that is not clear to me is if the coordinates of GML features that can be embedded in the GMLJP2CoverageCollection are expressed in pixel coordinates or in georeferenced coordinates. I may have miss something in the doc... The example at page 47-48 would lead me to think this is pixel coordinates because of the bounding box of the coverage collection. At first sight, I'd say that the current GMLJP2 reader in GDAL should be able to cope with GMLJP2 2.0 (limited to retrieving SRS + geotransformation matrix) with few, if any, changes (metadata or features left apart). The write part would need changes of course. feature 67 in the reader requirements box seems to be an extra annoyance to handle. I'm wondering who will really implement such a chek in the reading part, so it suse is probably just an opportunity to burn a few extra trees by people printing the spec. Oh well... Even Mateusz Åoskot mateusz at loskot.net writes: Hi, I think this may be of interested within the GDAL community: http://www.opengeospatial.org/pressroom/pressreleases/1965 Hi, First time ever I tried to send feedback to OGC. Let's see if my mail went through. I commented two issues: 1. It looks like OGC has defined that origin in georeferencing means the centre of pixel in change number 6: Clarification of the use of CRS and Rectified grid coverage / image georeference with origin point (at pixel center). Is this interpretation right and could it be expressed in some fool proof way, like Origin of the RectifiedGrid is placed at the centre point of the corner pixel 2. Throughout the paper srsNames are given in two different ways. - srsName=http://www.opengis.net/def/crs/EPSG/0/4326; - srsName=urn:ogc:def:crs:EPSG::4326 In one example there is even this. - srsName=EPSG:4326 I believe that it means that both http and urn versions can be used but there was not enough room in the 91 pages long document to tell that. Perhaps the meaning is to be explicit and therefore there is a reference to another document with number OGC 07-092r3 http://portal.opengeospatial.org/files/?artifact_id=30575 However, reading OGC 07-092r3 does not help, that document does not mention at all that srsName=http://www.opengis.net/def/crs/EPSG/0/4326; could be used but it knows only the urn syntax. The same thing in with units of measures. There is a table 3 URIs for units-of-measure that gives examples of how to refer to UoM and they are like - http://www.opengis.net/def/uom/OGC/1.0/metre or - http://www.opengis.net/def/uom/EPSG/6.3/9001 But in XML examples UoMs are expressed mostly as - uom=urn:ogc:def:uom:EPSG::9001 There seems to be also at least one copy-paste error in the examples: Envelope srsName=http://www.opengis.net/def/crs/EPSG/0/4326; axisLabels=Lat Long uomLabels=deg deg srsDimension=2 lowerCorner270379.500 3942462.000/lowerCorner upperCorner518842.500 3942462.000/upperCorner /Envelope -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
Hello everyone Continuing the previous discussion, I would like to propose something and the community's suggestions are welcomed/needed. I can understand that this thread is a little old, so let me remind you that its regarding the automatic geo-referencer idea. The idea is also proposed on the GDAL ideas page (http://trac.osgeo.org/gdal/wiki/SummerOfCode). Based on the previous discussions, what came out was that we can improve the current implementation of SIMPLE SURF in GDAL which was developed as a part of 2012 GSOC GDAL Correlator project, to support *large data* and *multi spectral imagery*. And then apply this *modified* algorithm for the geo-reference purposes. Now I have been in touch with Chaitanya, who is willing to mentor this project, and there are some things on which we would like to know community's suggestions/response. There are basically two things that can be done regarding this project: 1. As mentioned above, we can modify the SIMPLE SURF algorithm and make it much better for the geo-reference purposes. Already, a lot had been discussed on this and we have a fairly good idea about what is to be done. 2. One more thing that can be done is that we can implement BRISK algorithm[1] instead of SURF along with the FLANN matcher for this purpose. What advantages this thing offers is that it is fairly fast and gives comparable outputs along with that it works well with fairly large data sets. So we do not need to segment the imagery as we would have done in the case of SURF. Also added to this, this algorithm also has no patent issues. We had a lot of problem regarding patent issues in SIFT/SURF and we discussed them at length on the mailing list as well. One thing that I fell can be done is that two proposal can be written, one for each and then community can decide accordingly which one is more useful. Or we can decide it here itself..? Kindly provide your valuable comments and suggestion.. With Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad 1. http://www.robots.ox.ac.uk/~vgg/rg/papers/brisk.pdf On Thu, Feb 13, 2014 at 2:23 PM, Kshitij Kansal kansa...@gmail.com wrote: Hello Everyone I have updated the Summer Of Code Ideas Page for GDAL. I have Introduced the above idea in that page also. Mr. Chaitanya Kumar is willing to mentor the project. Please look into this. Suggestions and Comments are welcomed. Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad On Sat, Feb 8, 2014 at 2:07 PM, Dmitriy Baryshnikov bishop@gmail.comwrote: Hi, Even note that you cannot get the code from this projects and merge it to GDAL, but you free to develop you own implementation of this algorithms as path of GDAL. This is a same situation with correlator. Andrew cannot get code from OpenCV and GRASS as incompatible licenses, so the own (simple) implementation was provided. One can change this implementation to be more advanced: support large datasets, more bands, etc. Everybody welcome to do it. Best regards, Dmitry 08.02.2014 2:15, Kshitij Kansal пишет: Sir I am providing the links for both the algorithms that I talked. I am new to this licence issues thing so I would be highly grateful if you can clarify doubts and if can proceed on working for this idea. http://www.cs.ubc.ca/~lowe/keypoints/ (SIFT) http://www.ipol.im/pub/art/2011/my-asift/ (ASIFT) [here source code is provided. It contains license ] http://www.cmap.polytechnique.fr/~yu/research/ASIFT/demo.html (Demo Page for ASIFT) The SIFT algorithm in itself is patented. They only provide binaries. I am not sure If we can use those binaries or not. As far as ASIFT is concerned, i think its implementation is only patented. Kindly clarify this. Thanking You With Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad On Sat, Feb 8, 2014 at 2:23 AM, Even Rouault even.roua...@mines-paris.org wrote: Selon Kshitij Kansal kansa...@gmail.com: Kshitij, I'm surprised that you mention licenses for algorithms. What are your sources for that? Only *implementations* can be licensed not algorithms themselves. So if you develop your own implementation you are free to select the license you wish. There might be issues linked to potential pattents in some countries but that is acceptable in my opinion as software parents are not valid in all contries so mentionning potential issues with them in the documentation is sufficient . Hello Based on all suggestion ins and comments above, I have come up with one thing. The most important thing that could have been a road block for this project was licence issues which was pointed by Even Rouault. I am interested in implementing the SIFT or ASIFT algorithms for automatic geo-referencing which I proposed in above mails. I am interested in making a separate tool which will be completely based on the GDAL and maintained by GDAL community. I
[gdal-dev] Motion: Commit Access for Vincent Mora
Motion: Extend GDAL/OGR commit access to Vincent Mora. --- I'd like to make it easier for Vincent to maintain and improve the recently committed OGR WaSP driver, without me being the bottleneck. He has demonstrated a good knowledge of OGR working, and good interaction with our community. Vincent, could you answer to this email to state that you have read and agreed to the GDAL commiter guidelines : http://trac.osgeo.org/gdal/wiki/rfc3_commiters I'll start the voting with: +1 Even Best regards, -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Commit Access for Vincent Mora
On 14/03/2014 16:42, Even Rouault wrote: Motion: Extend GDAL/OGR commit access to Vincent Mora. --- I'd like to make it easier for Vincent to maintain and improve the recently committed OGR WaSP driver, without me being the bottleneck. He has demonstrated a good knowledge of OGR working, and good interaction with our community. Vincent, could you answer to this email to state that you have read and agreed to the GDAL commiter guidelines : http://trac.osgeo.org/gdal/wiki/rfc3_commiters I'll start the voting with: +1 Even Best regards, I have read and agreed to the GDAL commiter guidelines : http://trac.osgeo.org/gdal/wiki/rfc3_commiters ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
Hi, I think we need to decide it here, not to create lot of proposals. The second idea is very interesting. Maybe it worth to create some common interface (or API) to add new methods BRISK, SURF, SIFT etc. You can develop you realisation of BRISK and demonstrate how-to one can use it via such common interface. E.g. in GDALComputeMatchingPoints add enum for algorithms or use exist papszOptions. Best regards, Dmitry 14.03.2014 17:28, Kshitij Kansal ?: Hello everyone Continuing the previous discussion, I would like to propose something and the community's suggestions are welcomed/needed. I can understand that this thread is a little old, so let me remind you that its regarding the automatic geo-referencer idea. The idea is also proposed on the GDAL ideas page (http://trac.osgeo.org/gdal/wiki/SummerOfCode). Based on the previous discussions, what came out was that we can improve the current implementation of SIMPLE SURF in GDAL which was developed as a part of 2012 GSOC GDAL Correlator project, to support *large data* and *multi spectral imagery*. And then apply this *modified* algorithm for the geo-reference purposes. Now I have been in touch with Chaitanya, who is willing to mentor this project, and there are some things on which we would like to know community's suggestions/response. There are basically two things that can be done regarding this project: 1. As mentioned above, we can modify the SIMPLE SURF algorithm and make it much better for the geo-reference purposes. Already, a lot had been discussed on this and we have a fairly good idea about what is to be done. 2. One more thing that can be done is that we can implement BRISK algorithm[1] instead of SURF along with the FLANN matcher for this purpose. What advantages this thing offers is that it is fairly fast and gives comparable outputs along with that it works well with fairly large data sets. So we do not need to segment the imagery as we would have done in the case of SURF. Also added to this, this algorithm also has no patent issues. We had a lot of problem regarding patent issues in SIFT/SURF and we discussed them at length on the mailing list as well. One thing that I fell can be done is that two proposal can be written, one for each and then community can decide accordingly which one is more useful. Or we can decide it here itself..? Kindly provide your valuable comments and suggestion.. With Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad 1. http://www.robots.ox.ac.uk/~vgg/rg/papers/brisk.pdf http://www.robots.ox.ac.uk/%7Evgg/rg/papers/brisk.pdf ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Commit Access for Vincent Mora
+1 Frank On Fri, Mar 14, 2014 at 8:42 AM, Even Rouault even.roua...@mines-paris.orgwrote: Motion: Extend GDAL/OGR commit access to Vincent Mora. --- I'd like to make it easier for Vincent to maintain and improve the recently committed OGR WaSP driver, without me being the bottleneck. He has demonstrated a good knowledge of OGR working, and good interaction with our community. Vincent, could you answer to this email to state that you have read and agreed to the GDAL commiter guidelines : http://trac.osgeo.org/gdal/wiki/rfc3_commiters I'll start the voting with: +1 Even Best regards, -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
Kshitij, What is the performance of the proposed algorithms for very large rasters? If one of them is good with large images that's a cleaner choice without all the workaround with scaling the rasters. -- Best regards, Chaitanya Kumar CH On 15-Mar-2014 12:22 am, Dmitriy Baryshnikov bishop@gmail.com wrote: Hi, I think we need to decide it here, not to create lot of proposals. The second idea is very interesting. Maybe it worth to create some common interface (or API) to add new methods BRISK, SURF, SIFT etc. You can develop you realisation of BRISK and demonstrate how-to one can use it via such common interface. E.g. in GDALComputeMatchingPoints add enum for algorithms or use exist papszOptions. Best regards, Dmitry 14.03.2014 17:28, Kshitij Kansal пишет: Hello everyone Continuing the previous discussion, I would like to propose something and the community's suggestions are welcomed/needed. I can understand that this thread is a little old, so let me remind you that its regarding the automatic geo-referencer idea. The idea is also proposed on the GDAL ideas page (http://trac.osgeo.org/gdal/wiki/SummerOfCode). Based on the previous discussions, what came out was that we can improve the current implementation of SIMPLE SURF in GDAL which was developed as a part of 2012 GSOC GDAL Correlator project, to support *large data* and *multi spectral imagery*. And then apply this *modified* algorithm for the geo-reference purposes. Now I have been in touch with Chaitanya, who is willing to mentor this project, and there are some things on which we would like to know community's suggestions/response. There are basically two things that can be done regarding this project: 1. As mentioned above, we can modify the SIMPLE SURF algorithm and make it much better for the geo-reference purposes. Already, a lot had been discussed on this and we have a fairly good idea about what is to be done. 2. One more thing that can be done is that we can implement BRISK algorithm[1] instead of SURF along with the FLANN matcher for this purpose. What advantages this thing offers is that it is fairly fast and gives comparable outputs along with that it works well with fairly large data sets. So we do not need to segment the imagery as we would have done in the case of SURF. Also added to this, this algorithm also has no patent issues. We had a lot of problem regarding patent issues in SIFT/SURF and we discussed them at length on the mailing list as well. One thing that I fell can be done is that two proposal can be written, one for each and then community can decide accordingly which one is more useful. Or we can decide it here itself..? Kindly provide your valuable comments and suggestion.. With Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad 1. http://www.robots.ox.ac.uk/~vgg/rg/papers/brisk.pdf ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
