OSGeo - User contributions [en]

Google Summer of Code 2016 Accepted

2016-06-06T20:45:48Z

Wiki-Hao2309: /* Accepted Proposals */

<center>
[[Image:GSoC2016Logo.jpg|500px|link=https://summerofcode.withgoogle.com/]] @ [[Image:OSGeo_300_127_pixel.png|200px|link=http://www.osgeo.org]]
</center>

* Back to the main OSGeo [[Google Summer of Code 2016]] @ OSGeo wiki page.

== Accepted Proposals ==

This year OSGeo accepted 22 students working on the following projects.

{|class="wikitable sortable" border="2" cellspacing="0" cellpadding="4" rules="all" style="margin:1em 1em 1em 0; border:solid 1px #AAAAAA; border-collapse:collapse; background-color:#D7E3D1; font-size:95%; empty-cells:show;"
|'''Community'''
|'''Project'''
|'''Student'''
|'''1st mentor'''
|'''2nd mentor'''
|'''Wiki page'''
|'''Repository'''
|-
|GDAL
|Introduce Triangulated Surface, Polyhedral Surface and Triangle API in the OGRGeometry core and implement their support in OGR drivers for GDAL
|Avyav Kumar Singh
|Rob Emanuele
|Even Rouault
|[https://github.com/avyavkumar/gdal/wiki Github]
|
|-
|GDAL
|GDAL DWG support
|Alexandr Borzykh
|Dmitry Baryshnikov
|Even Rouault
|[https://wiki.osgeo.org/wiki/GDALDWG_SoC_2016 Wiki]
|[https://github.com/sandyre/libopencad Github]
|-
|GRASS GIS
|Complete basic cartography suite in GRASS GIS wxGUI Map Display
|Adam Laža
|Anna Petrasova
|Vaclav Petras
|[https://trac.osgeo.org/grass/wiki/GSoC/2016/BasicCartographySuiteInGRASS Trac]
|
|-
|GRASS GIS
|GRASS GIS - Additional segmentation algorithms for i.segment
|Bo Yang
|Moritz Lennert
|Markus Neteler
|[https://trac.osgeo.org/grass/wiki/GSoC/2016/Additional_segmentation_algorithms Trac]
|[https://trac.osgeo.org/grass/browser/sandbox/bo/i.segment.gsoc2016 Sandbox]
|-
|GRASS GIS
|GRASS GIS - PyQt implementation of GUI forms generated automatically from XML
|Ondřej Pešek
|Vaclav Petras
|Anna Petrasova
|[https://trac.osgeo.org/grass/wiki/GSoC/2016/PyQtGUI Trac]
|
|-
|GRASS GIS
|GRASS GIS - WEBGRASS
|Mayank Agrawal
|Rashad Kanavath
|Massimo Di Stefano
|[https://github.com/mayank33/webgrass/wiki Wiki]
|
|-
|gvSIG
|Add tests and educational games support to gvSIG Educa.
|Carlos I. Colombana
|Oscar Martinez
|Joaquin del Cerro
|[[GvSIG-Educational-Games_GSoC_2016|Wiki]]
|
|-
|gvSIG
|Development of a model for woody debris flooding hazard in gvSIG
|Silvia Franceschi
|Andrea Antonello
|Riccardo Rigon
|[https://github.com/moovida/jgrasstools/wiki/Google-Summer-of-Code-2016 github]
|[https://github.com/silviafranceschi/jgrasstools github]
|
|-
|istSOS
|Android istSOS client
|Florin-Daniel Cioloboc
|Mirko Cardoso
|Milan Antonovic
|[https://wiki.osgeo.org/wiki/Android_istSOS Wiki]
|[https://github.com/istSOS/java-core Github] [https://github.com/masterflorin/java-core Fork]
|-
|istSOS
|istSOS Web API
|Luka Glušica
|Massimiliano Cannata
|Milan Antonovic
|[https://wiki.osgeo.org/wiki/IstSOS_Web_API Wiki]
|[https://github.com/istSOS/javascript-core GitHub] [https://github.com/WebPractice-LukaG/javascript-core Fork]
|-
|istSOS
|VistSOS: the istSOS Data Visualization Framework
|Felipe Poveda
|Milan Antonovic
|Massimiliano Cannata
|[https://wiki.osgeo.org/wiki/VistSOS_Data_Visualization_Framework Wiki]
|
|-
|NASA World Wind
|NASA Web World Wind - Multidimensional Visualization Tool for Environmental Variables
|Gabriele Prestifilippo
|Jakub Balhar
|Patrick Hogan
|[[NASA Web WorldWind Multidimension Visualization Tool GSoC 2016|Wiki]]
|
|-
|OpenLayers3 - Google maps
|OGC protocols support within OL3-Google-Maps
|Samuel Lapointe
|Alexandre Dube
|Jessica Lapointe
|[[OL3-GoogleMaps_GSoC_2016|Wiki]]
|
|-
|OneBusAway/Transitime
|Tansitime Quickstart application
|Brendan Egan
|Og Crudden
|Stefan Steiner
|[https://github.com/Egan109/core/wiki/Transitime-QuickStart-Gsoc-2016 Github Wiki]
|
|-
|OSSIM
|A complete photogrammetric OSSIM tool for automatic DSMs generation using multi-view optical and SAR images
|Martina Di Rita
|Oscar Kramer
|Dave Burken
|[https://trac.osgeo.org/ossim/wiki/GSoC_2016 Wiki]
|
|-
|pgRouting
|Flow Algorithms for pgRouting
|Andrea Nardelli
|Daniel Kastl
|Vicky Vergara
|[https://github.com/Illedran/pgrouting/wiki/GSoC-2016-Flow Github Wiki]
|
|-
|pgRouting
|Implementation of a framework which supports addition of contraction techniques for pgRouting
|Sankepally Rohith Reddy
|Vicky Vergara
|Daniel Kastl
|[https://github.com/sankepallyrohithreddy/pgrouting/wiki/GSoc-2016-Contraction Github Wiki]
|
|-
|PyWPS
|Remote Output Storage for PyWPS
|Vikas Mishra
|Jachym Cepicky
|Jonas Eberle
|[https://wiki.osgeo.org/wiki/User:Vikasmishra95 Wiki]
|
|-
|PyWPS
|Web-based administration & process management for PyWPS
|Jan Rudolf
|Jonas Eberle
|Jachym Cepicky
|[https://wiki.osgeo.org/wiki/GSoC_2016_Web_administration_and_process_management_for_PyWPS Wiki]
|
|-
|QGIS
|QGIS Styles, Symbols, and SVG Markers Sharing Repository
|Akbar Gumbira
|Alessandro Pasotti
|Anita Graser
|[[QGIS Sharing Repository|Wiki]]
|
|-
|ZOO-Project
|Bringing pyModis to the web through ZOO-Project
|Chingchai Humhong
|Luca Delucchi
|Gerald Fenoy
|[http://zoo-project.org/trac/wiki/Bringing_pyModis_to_the_web_through_ZOO-Project_GSoC_2016 Wiki]
|[https://github.com/chingchai/pyModis/tree/gsoc-2016/zoo-pymodis/ Github]
|-
|ZOO-Project
|Implementing WPS for Geopaparazzi field data collection tool using ZOO-Project: Simplifying integration of field data and GIS
|Niroshan Sanjaya
|Gerald Fenoy
|Andrea Antonello
|[http://zoo-project.org/trac/wiki/IMPLEMENTING_WPS_FOR_GEOPAPARAZZI_FIELD_DATA_COLLECTION_TOOL_USING_ZOO-PROJECT%3ASIMPLIFYING_INTEGRATION_OF_FIELD_DATA_AND_GIS Wiki]
|
|-
|}

See the [https://summerofcode.withgoogle.com/organizations/6273632556810240/ accepted projects on Google's platform].

[[Category: Google Summer of Code]]

Google Summer of Code 2016 Accepted

2016-06-06T20:42:03Z

Wiki-Hao2309: /* Accepted Proposals */

<center>
[[Image:GSoC2016Logo.jpg|500px|link=https://summerofcode.withgoogle.com/]] @ [[Image:OSGeo_300_127_pixel.png|200px|link=http://www.osgeo.org]]
</center>

* Back to the main OSGeo [[Google Summer of Code 2016]] @ OSGeo wiki page.

== Accepted Proposals ==

This year OSGeo accepted 22 students working on the following projects.

{|class="wikitable sortable" border="2" cellspacing="0" cellpadding="4" rules="all" style="margin:1em 1em 1em 0; border:solid 1px #AAAAAA; border-collapse:collapse; background-color:#D7E3D1; font-size:95%; empty-cells:show;"
|'''Community'''
|'''Project'''
|'''Student'''
|'''1st mentor'''
|'''2nd mentor'''
|'''Wiki page'''
|'''Repository'''
|-
|GDAL
|Introduce Triangulated Surface, Polyhedral Surface and Triangle API in the OGRGeometry core and implement their support in OGR drivers for GDAL
|Avyav Kumar Singh
|Rob Emanuele
|Even Rouault
|[https://github.com/avyavkumar/gdal/wiki Github]
|
|-
|GDAL
|GDAL DWG support
|Alexandr Borzykh
|Dmitry Baryshnikov
|Even Rouault
|[https://wiki.osgeo.org/wiki/GDALDWG_SoC_2016 Wiki]
|[https://github.com/sandyre/libopencad Github]
|-
|GRASS GIS
|Complete basic cartography suite in GRASS GIS wxGUI Map Display
|Adam Laža
|Anna Petrasova
|Vaclav Petras
|[https://trac.osgeo.org/grass/wiki/GSoC/2016/BasicCartographySuiteInGRASS Trac]
|
|-
|GRASS GIS
|GRASS GIS - Additional segmentation algorithms for i.segment
|Bo Yang
|Moritz Lennert
|Markus Neteler
|[https://trac.osgeo.org/grass/wiki/GSoC/2016/Additional_segmentation_algorithms Trac]
|
|-
|GRASS GIS
|GRASS GIS - PyQt implementation of GUI forms generated automatically from XML
|Ondřej Pešek
|Vaclav Petras
|Anna Petrasova
|[https://trac.osgeo.org/grass/wiki/GSoC/2016/PyQtGUI Trac]
|
|-
|GRASS GIS
|GRASS GIS - WEBGRASS
|Mayank Agrawal
|Rashad Kanavath
|Massimo Di Stefano
|[https://github.com/mayank33/webgrass/wiki Wiki]
|
|-
|gvSIG
|Add tests and educational games support to gvSIG Educa.
|Carlos I. Colombana
|Oscar Martinez
|Joaquin del Cerro
|[[GvSIG-Educational-Games_GSoC_2016|Wiki]]
|
|-
|gvSIG
|Development of a model for woody debris flooding hazard in gvSIG
|Silvia Franceschi
|Andrea Antonello
|Riccardo Rigon
|[https://github.com/moovida/jgrasstools/wiki/Google-Summer-of-Code-2016 github]
|[https://github.com/silviafranceschi/jgrasstools github]
|
|-
|istSOS
|Android istSOS client
|Florin-Daniel Cioloboc
|Mirko Cardoso
|Milan Antonovic
|[https://wiki.osgeo.org/wiki/Android_istSOS Wiki]
|[https://github.com/istSOS/java-core Github] [https://github.com/masterflorin/java-core Fork]
|-
|istSOS
|istSOS Web API
|Luka Glušica
|Massimiliano Cannata
|Milan Antonovic
|[https://wiki.osgeo.org/wiki/IstSOS_Web_API Wiki]
|[https://github.com/istSOS/javascript-core GitHub] [https://github.com/WebPractice-LukaG/javascript-core Fork]
|-
|istSOS
|VistSOS: the istSOS Data Visualization Framework
|Felipe Poveda
|Milan Antonovic
|Massimiliano Cannata
|[https://wiki.osgeo.org/wiki/VistSOS_Data_Visualization_Framework Wiki]
|
|-
|NASA World Wind
|NASA Web World Wind - Multidimensional Visualization Tool for Environmental Variables
|Gabriele Prestifilippo
|Jakub Balhar
|Patrick Hogan
|[[NASA Web WorldWind Multidimension Visualization Tool GSoC 2016|Wiki]]
|
|-
|OpenLayers3 - Google maps
|OGC protocols support within OL3-Google-Maps
|Samuel Lapointe
|Alexandre Dube
|Jessica Lapointe
|[[OL3-GoogleMaps_GSoC_2016|Wiki]]
|
|-
|OneBusAway/Transitime
|Tansitime Quickstart application
|Brendan Egan
|Og Crudden
|Stefan Steiner
|[https://github.com/Egan109/core/wiki/Transitime-QuickStart-Gsoc-2016 Github Wiki]
|
|-
|OSSIM
|A complete photogrammetric OSSIM tool for automatic DSMs generation using multi-view optical and SAR images
|Martina Di Rita
|Oscar Kramer
|Dave Burken
|[https://trac.osgeo.org/ossim/wiki/GSoC_2016 Wiki]
|
|-
|pgRouting
|Flow Algorithms for pgRouting
|Andrea Nardelli
|Daniel Kastl
|Vicky Vergara
|[https://github.com/Illedran/pgrouting/wiki/GSoC-2016-Flow Github Wiki]
|
|-
|pgRouting
|Implementation of a framework which supports addition of contraction techniques for pgRouting
|Sankepally Rohith Reddy
|Vicky Vergara
|Daniel Kastl
|[https://github.com/sankepallyrohithreddy/pgrouting/wiki/GSoc-2016-Contraction Github Wiki]
|
|-
|PyWPS
|Remote Output Storage for PyWPS
|Vikas Mishra
|Jachym Cepicky
|Jonas Eberle
|[https://wiki.osgeo.org/wiki/User:Vikasmishra95 Wiki]
|
|-
|PyWPS
|Web-based administration & process management for PyWPS
|Jan Rudolf
|Jonas Eberle
|Jachym Cepicky
|[https://wiki.osgeo.org/wiki/GSoC_2016_Web_administration_and_process_management_for_PyWPS Wiki]
|
|-
|QGIS
|QGIS Styles, Symbols, and SVG Markers Sharing Repository
|Akbar Gumbira
|Alessandro Pasotti
|Anita Graser
|[[QGIS Sharing Repository|Wiki]]
|
|-
|ZOO-Project
|Bringing pyModis to the web through ZOO-Project
|Chingchai Humhong
|Luca Delucchi
|Gerald Fenoy
|[http://zoo-project.org/trac/wiki/Bringing_pyModis_to_the_web_through_ZOO-Project_GSoC_2016 Wiki]
|[https://github.com/chingchai/pyModis/tree/gsoc-2016/zoo-pymodis/ Github]
|-
|ZOO-Project
|Implementing WPS for Geopaparazzi field data collection tool using ZOO-Project: Simplifying integration of field data and GIS
|Niroshan Sanjaya
|Gerald Fenoy
|Andrea Antonello
|[http://zoo-project.org/trac/wiki/IMPLEMENTING_WPS_FOR_GEOPAPARAZZI_FIELD_DATA_COLLECTION_TOOL_USING_ZOO-PROJECT%3ASIMPLIFYING_INTEGRATION_OF_FIELD_DATA_AND_GIS Wiki]
|
|-
|}

See the [https://summerofcode.withgoogle.com/organizations/6273632556810240/ accepted projects on Google's platform].

[[Category: Google Summer of Code]]

GRASS GSoC 2016 Segment Algorithms

2016-05-30T15:28:34Z

Wiki-Hao2309:

'''Welcome to ''OSGeo Wiki''!'''
We hope you will contribute much and well.
You will probably want to read the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages].
Again, welcome and have fun! [[User:Neteler|Neteler]] ([[User talk:Neteler|talk]]) 14:50, 29 April 2016 (PDT)

== GRASS GSoC 2016 Additional Image Segmentation Algorithms for i.segment ==

{| {{Prettytable}}
| Student Name:
| Bo Yang
|-
| Organization:
| [http://www.osgeo.org/ OSGeo - Open Source Geospatial Foundation]
|-
| Mentors:
| Moritz Lennert, Markus Metz
|-
| Title:
| Additional segmentation algorithms for [https://grass.osgeo.org/grass71/manuals/i.segment.html i.segment]
|-
| Repository:
| GRASS 7, browse at: [https://trac.osgeo.org/grass/browser/sandbox/bo/i.segment.gsoc2016 i.segment sandbox]
|}

GRASS GIS has the i.segment which provides the possibility to segment an image into objects. This is a basic step in object-based image analysis (OBIA). Currently, the module only provides one segmentation algorithm: region-growing. The code of i.segment was structured in a way that allows addition of other algorithms. The core of proposed GSoC project would thus be to add a series of these algorithms. It would be more useful and comprehensive to add more segment methods to the i.segment module, such as mean-shift and watershed, which could be used in more types of satellite image processing. Special care should be taken for the whole project to code as efficiently as possible, i.e. to make the code run in reasonable time, even for very large images.

Idea for this project was suggested by Moritz at [https://trac.osgeo.org/grass/wiki/GSoC/2016/ GRASS GIS SoC Ideas].

== Background ==

* Image segmentation or object recognition is the process of grouping similar pixels into unique objects. Segmentation of remote sensing images is a challenging task. A myriad of different methods have been proposed and implemented in recent years. In spite of the huge effort invested in this problem, there is no single approach that can generally solve the problem of segmentation for the large variety of image modalities existing today. The most effective segmentation algorithms are obtained by carefully customizing combinations of components. The parameters of these components are tuned for the characteristics of the image modality used as input and the features of the objects to be segmented. [1]
* In the GRASS i.segment module currently only region growing and merging algorithm is implemented. Each object found during the segmentation process is given a unique ID and is a collection of contiguous pixels meeting some criteria. Note the contrast with image classification where all pixels similar to each other are assigned to the same class and do not need to be contiguous. The image segmentation results can be useful on their own, or used as a preprocessing step for image classification. The segmentation preprocessing step can reduce noise and speed up the classification. [2]

== Segmentation Methods ==

* 1. Region growing and merging (available in i.segment module )
This segmentation algorithm sequentially examines all current segments in the raster map. The similarity between the current segment and each of its neighbors is calculated according to the given distance formula. The basic approach of a region growing algorithm is to start from a seed region (typically one or more pixels) that are considered to be inside the object to be segmented. The pixels neighboring this region are evaluated to determine if they should also be considered part of the object. If so, they are merge to the region and the process continues as long as new pixels are added to the region [3].
* 2. Mean-shift (plan to be implemented during GSoC 2016)
The mean shift segmentation is a local homogenization technique that is very useful for damping shading or tonality differences in localized objects. For the algorithm implementation of this case, basically the algorithm replaces each pixel with the mean of the pixels in a range-r neighborhood and whose value is within a distance d. The Mean Shift takes usually 3 inputs: 1) A distance function for measuring distances between pixels. Usually the Euclidean distance, but any other well defined distance function could be used. The Manhattan Distance is another useful choice sometimes. 2) A radius. All pixels within this radius (measured according the above distance) will be accounted for the calculation. 3) A value difference. From all pixels inside radius r, we will take only those whose values are within this difference for calculating the mean [4].

* 3. Watershed (plan to be implemented during GSoC 2016)
Watershed segmentation classifies pixels into regions using gradient descent on image features and analysis of weak points along region boundaries. Imagine water raining onto a landscape topology and flowing with gravity to collect in low basins. The size of those basins will grow with increasing amounts of precipitation until they spill into one another, causing small basins to merge together into larger basins. Catchment basins are formed by using local geometric structure to associate points in the image domain with local extrema in some feature measurement such as curvature or gradient magnitude. The watersheds technique is also more flexible in that it does not produce a single image segmentation, but rather a hierarchy of segmentations from which a single region or set of regions can be extracted a-priori, using a threshold, or interactively, with the help of a graphical user interface.

== Schedule ==

* Preparation: Discuss with Mentors. Gather ideas from the community. Feature requests, image segmentation literature, and any other ideas and suggestions.
* 16 – 21 May week 0: Setup coding environmental, get familiar with programming manual, test through existing code.
* 23 -- 28 May week 1: Start coding, develop pseudo code to outline the work
* 30 May -- 4 June week 2: implement mean-shift image segmentation algorithm
* 6 -- 11 June week 3: Validation mean-shift algorithm
* 13 -- 18 June week 4: Debugging mean-shift algorithm
* 20 -- 26 June Week 5: Caching week, further refine and validate the code
* 27 June Mid-term evaluation: Evaluate the existing program, determine the plan for the remaining 3-4 weeks.
* 28 June -- 2 July Week 6: based on the evaluation of the mid-term, test and ensure a solid existing program.
* 4 -- 9 July Week 7: Implement watershed image segmentation algorithm
* 11 -- 16 July Week 8: Validation and debugging watershed algorithm
* 18 -- 23 July: Further refine tests and documentation for the whole project.
* 25 July – 13 August Week 9-11: Improving the main algorithm, if time permits, adding shape as an additional merge criteria,
* 15 August - 23 August Final week: Tidy code, write tests, improve documentation and submit code sample.

== Main Goal ==

Implement more image segmentation methods to extend the available i.segment for image processing in GRASS. As the general logistics of the i.segment module is in place, adding mean-shift and watershed segmentation algorithms should be possible. The core of the GSoC project thus is to add a series of these algorithms. In addition, the current implementation only uses distance within the multidimensional space of all input bands as the criteria whether to merge segments or not. Adding shape as an additional merge criteria will be helpful. If time permits, this feature of additional shape criteria will be implemented.

== ToDo List ==
* Get an OSGeo user id [http://www.osgeo.org/osgeo_userid/]: this will give you access to trac, including the wiki part of trac
* Set up a complete build environment allowing you to check out different versions of GRASS, compile and run them [https://grasswiki.osgeo.org/wiki/Compile_and_Install]
* Read the programming manual [https://grass.osgeo.org/programming7/], notably the chapters General (aka GIS Library), Imagery, Raster, Segment
* Read submitting (coding standard) rules [https://trac.osgeo.org/grass/wiki/Submitting], especially the C-rules.
* Register on the OSGeo wiki (making yourself automatically a member of OSgeo)
* More will be added...

== Possible difficulties and solution ==

As it usually happens with software development, I might come across problems during implementation of the above mentioned ideas which may take longer than I expected, in such a case, I have kept two weeks (week 5 and week 9) as caching weeks which are intended to let me catch up on unimplemented parts of the project.
I will be working on this project full time as of now. I plan to keep in touch with my mentor as much as I can and will be reporting to him every time I am done with finishing things on my to-do list. My college semester ends on May 5. New semester starts at the middle of August and hence only about one weeks of the GSoC project would overlap with college work, this will not be a problem as there isn’t much work in the first few weeks of college. After that, I have no other obligations whatsoever and am completely free to work on the project.
If my project need more work or maintenance after the summer ends, I would love to stick around and help. I actually have an own idea and want to implement and add to the GRASS lib after the training through GSoC. Afterwards I will look at other projects and see what I’m interested in.

== Student's Biography ==

My name is Bo Yang, I have finished Master degree in Geography at [http://www.UC.edu/ University of Cincinnati], now I am in the second year of Ph.D. study of Geography at UC. I also have a bachelor degree in Mathematics and MS in Computer Science. I like Python language, but I have also used other languages (C language, PHP), and have utilized QGIS and GRASS a lot in my study and research project.
* Email: hao2309@gmail.com

== References ==
* [1] OTB software guide: https://www.orfeo-toolbox.org/packages/OTBSoftwareGuide.pdf
* [2] GRASS Manuals: https://grass.osgeo.org/grass71/manuals/i.segment.html
* [3] Comaniciu, D., & Meer, P. (2002). Mean shift: a robust approach toward feature space analysis. IEEE Transactions on Pattern Analysis and Machine Intelligence, 24(5), 1–37.
* [4] http://stackoverflow.com/questions/4831813/image-segmentation-using-mean-shift-explained

[[Category:Google Summer of Code]]

GRASS GSoC 2016 Segment Algorithms

2016-05-30T15:27:21Z

Wiki-Hao2309:

'''Welcome to ''OSGeo Wiki''!'''
We hope you will contribute much and well.
You will probably want to read the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages].
Again, welcome and have fun! [[User:Neteler|Neteler]] ([[User talk:Neteler|talk]]) 14:50, 29 April 2016 (PDT)

== GRASS GSoC 2016 Additional Image Segmentation Algorithms for i.segment ==

{| {{Prettytable}}
| Student Name:
| Bo Yang
|-
| Organization:
| [http://www.osgeo.org/ OSGeo - Open Source Geospatial Foundation]
|-
| Mentors:
| Moritz Lennert, Markus Metz
|-
| Title:
| Additional segmentation algorithms for [https://grass.osgeo.org/grass71/manuals/i.segment.html i.segment]
|-
| Repository:
| GRASS 7, browse at: [https://grass.osgeo.org/grass71/manuals/i.segment.html i.segment]
|}

GRASS GIS has the i.segment which provides the possibility to segment an image into objects. This is a basic step in object-based image analysis (OBIA). Currently, the module only provides one segmentation algorithm: region-growing. The code of i.segment was structured in a way that allows addition of other algorithms. The core of proposed GSoC project would thus be to add a series of these algorithms. It would be more useful and comprehensive to add more segment methods to the i.segment module, such as mean-shift and watershed, which could be used in more types of satellite image processing. Special care should be taken for the whole project to code as efficiently as possible, i.e. to make the code run in reasonable time, even for very large images.

Idea for this project was suggested by Moritz at [https://trac.osgeo.org/grass/wiki/GSoC/2016/ GRASS GIS SoC Ideas].

== Background ==

* Image segmentation or object recognition is the process of grouping similar pixels into unique objects. Segmentation of remote sensing images is a challenging task. A myriad of different methods have been proposed and implemented in recent years. In spite of the huge effort invested in this problem, there is no single approach that can generally solve the problem of segmentation for the large variety of image modalities existing today. The most effective segmentation algorithms are obtained by carefully customizing combinations of components. The parameters of these components are tuned for the characteristics of the image modality used as input and the features of the objects to be segmented. [1]
* In the GRASS i.segment module currently only region growing and merging algorithm is implemented. Each object found during the segmentation process is given a unique ID and is a collection of contiguous pixels meeting some criteria. Note the contrast with image classification where all pixels similar to each other are assigned to the same class and do not need to be contiguous. The image segmentation results can be useful on their own, or used as a preprocessing step for image classification. The segmentation preprocessing step can reduce noise and speed up the classification. [2]

== Segmentation Methods ==

* 1. Region growing and merging (available in i.segment module )
This segmentation algorithm sequentially examines all current segments in the raster map. The similarity between the current segment and each of its neighbors is calculated according to the given distance formula. The basic approach of a region growing algorithm is to start from a seed region (typically one or more pixels) that are considered to be inside the object to be segmented. The pixels neighboring this region are evaluated to determine if they should also be considered part of the object. If so, they are merge to the region and the process continues as long as new pixels are added to the region [3].
* 2. Mean-shift (plan to be implemented during GSoC 2016)
The mean shift segmentation is a local homogenization technique that is very useful for damping shading or tonality differences in localized objects. For the algorithm implementation of this case, basically the algorithm replaces each pixel with the mean of the pixels in a range-r neighborhood and whose value is within a distance d. The Mean Shift takes usually 3 inputs: 1) A distance function for measuring distances between pixels. Usually the Euclidean distance, but any other well defined distance function could be used. The Manhattan Distance is another useful choice sometimes. 2) A radius. All pixels within this radius (measured according the above distance) will be accounted for the calculation. 3) A value difference. From all pixels inside radius r, we will take only those whose values are within this difference for calculating the mean [4].

* 3. Watershed (plan to be implemented during GSoC 2016)
Watershed segmentation classifies pixels into regions using gradient descent on image features and analysis of weak points along region boundaries. Imagine water raining onto a landscape topology and flowing with gravity to collect in low basins. The size of those basins will grow with increasing amounts of precipitation until they spill into one another, causing small basins to merge together into larger basins. Catchment basins are formed by using local geometric structure to associate points in the image domain with local extrema in some feature measurement such as curvature or gradient magnitude. The watersheds technique is also more flexible in that it does not produce a single image segmentation, but rather a hierarchy of segmentations from which a single region or set of regions can be extracted a-priori, using a threshold, or interactively, with the help of a graphical user interface.

== Schedule ==

* Preparation: Discuss with Mentors. Gather ideas from the community. Feature requests, image segmentation literature, and any other ideas and suggestions.
* 16 – 21 May week 0: Setup coding environmental, get familiar with programming manual, test through existing code.
* 23 -- 28 May week 1: Start coding, develop pseudo code to outline the work
* 30 May -- 4 June week 2: implement mean-shift image segmentation algorithm
* 6 -- 11 June week 3: Validation mean-shift algorithm
* 13 -- 18 June week 4: Debugging mean-shift algorithm
* 20 -- 26 June Week 5: Caching week, further refine and validate the code
* 27 June Mid-term evaluation: Evaluate the existing program, determine the plan for the remaining 3-4 weeks.
* 28 June -- 2 July Week 6: based on the evaluation of the mid-term, test and ensure a solid existing program.
* 4 -- 9 July Week 7: Implement watershed image segmentation algorithm
* 11 -- 16 July Week 8: Validation and debugging watershed algorithm
* 18 -- 23 July: Further refine tests and documentation for the whole project.
* 25 July – 13 August Week 9-11: Improving the main algorithm, if time permits, adding shape as an additional merge criteria,
* 15 August - 23 August Final week: Tidy code, write tests, improve documentation and submit code sample.

== Main Goal ==

Implement more image segmentation methods to extend the available i.segment for image processing in GRASS. As the general logistics of the i.segment module is in place, adding mean-shift and watershed segmentation algorithms should be possible. The core of the GSoC project thus is to add a series of these algorithms. In addition, the current implementation only uses distance within the multidimensional space of all input bands as the criteria whether to merge segments or not. Adding shape as an additional merge criteria will be helpful. If time permits, this feature of additional shape criteria will be implemented.

== ToDo List ==
* Get an OSGeo user id [http://www.osgeo.org/osgeo_userid/]: this will give you access to trac, including the wiki part of trac
* Set up a complete build environment allowing you to check out different versions of GRASS, compile and run them [https://grasswiki.osgeo.org/wiki/Compile_and_Install]
* Read the programming manual [https://grass.osgeo.org/programming7/], notably the chapters General (aka GIS Library), Imagery, Raster, Segment
* Read submitting (coding standard) rules [https://trac.osgeo.org/grass/wiki/Submitting], especially the C-rules.
* Register on the OSGeo wiki (making yourself automatically a member of OSgeo)
* More will be added...

== Possible difficulties and solution ==

As it usually happens with software development, I might come across problems during implementation of the above mentioned ideas which may take longer than I expected, in such a case, I have kept two weeks (week 5 and week 9) as caching weeks which are intended to let me catch up on unimplemented parts of the project.
I will be working on this project full time as of now. I plan to keep in touch with my mentor as much as I can and will be reporting to him every time I am done with finishing things on my to-do list. My college semester ends on May 5. New semester starts at the middle of August and hence only about one weeks of the GSoC project would overlap with college work, this will not be a problem as there isn’t much work in the first few weeks of college. After that, I have no other obligations whatsoever and am completely free to work on the project.
If my project need more work or maintenance after the summer ends, I would love to stick around and help. I actually have an own idea and want to implement and add to the GRASS lib after the training through GSoC. Afterwards I will look at other projects and see what I’m interested in.

== Student's Biography ==

My name is Bo Yang, I have finished Master degree in Geography at [http://www.UC.edu/ University of Cincinnati], now I am in the second year of Ph.D. study of Geography at UC. I also have a bachelor degree in Mathematics and MS in Computer Science. I like Python language, but I have also used other languages (C language, PHP), and have utilized QGIS and GRASS a lot in my study and research project.
* Email: hao2309@gmail.com

== References ==
* [1] OTB software guide: https://www.orfeo-toolbox.org/packages/OTBSoftwareGuide.pdf
* [2] GRASS Manuals: https://grass.osgeo.org/grass71/manuals/i.segment.html
* [3] Comaniciu, D., & Meer, P. (2002). Mean shift: a robust approach toward feature space analysis. IEEE Transactions on Pattern Analysis and Machine Intelligence, 24(5), 1–37.
* [4] http://stackoverflow.com/questions/4831813/image-segmentation-using-mean-shift-explained

[[Category:Google Summer of Code]]

User talk:Weekly report

2016-05-30T14:52:45Z

Wiki-Hao2309:

GRASS GSoC 2016 Segment Algorithms/weekly report

2016-05-30T14:52:20Z

Wiki-Hao2309: Hao2309 moved page GRASS GSoC 2016 Segment Algorithms/weekly report to User talk:Weekly report: Weekly report page has been move to GRASS trac

#REDIRECT [[User talk:Weekly report]]

User talk:Weekly report

2016-05-30T14:52:20Z

Wiki-Hao2309: Hao2309 moved page GRASS GSoC 2016 Segment Algorithms/weekly report to User talk:Weekly report: Weekly report page has been move to GRASS trac

== GRASS GSoC 2016 Additional Image Segmentation Algorithms for i.segment ==

{| {{Prettytable}}
| Student Name:
| Bo Yang
|-
| Organization:
| [http://www.osgeo.org/ OSGeo - Open Source Geospatial Foundation]
|-
| Mentors:
| Moritz Lennert, Markus Neteler, Markus Metz
|-
| Title:
| Additional segmentation algorithms for [https://grass.osgeo.org/grass71/manuals/i.segment.html i.segment]
|-
| Repository:
| GRASS 7, browse at: [https://grass.osgeo.org/grass71/manuals/i.segment.html i.segment]
|}

== 16 – 21 May week 0: Setup coding environmental, get familiar with programming manual ==
* A small exercise too get you more familiar with basic GRASS code

{{{
As as part of bonding period, and as you are now able to compile GRASS, I would like to propose a small exercise which is already a first step in the direction of your project and which should allow you to become a bit more familiar with the code and with coding practices: As currently i.segment only provides one algorithm, the entire layout of the module GUI is related to that one algorithm. In the attached screenshot you see the current GUI. My idea would be to have the three mandatory inputs in the Required tab, then one tab per algorithm with algorithm-specific parameters, then the Optional tab. Otherwise, I'm afraid that the current'Settings' tab becomes overcrowded.
}}}

The code that defines options and which 'guisection' they are in is in parse_args.c [1]. For more info about how the command parser and its options work, see [2], but the existing examples in the code might already be enough.

You can add new parameters there without them being used in the code, yet, so don't hesitate, at this stage, to add one phony parameter per new algorithm, just to get the relevant tabs.

Once you've done this, compile just the i.segment module (by running make in the directory) and see if the GUI corresponds to what you aim for. Then, send me a diff of the code.

* Exercise has been finished
{{{
I think I've finished the exercise. For the time being I applied the following changes to the module GUI:
1. I kept "required" tab and add the selection of algorithms. Because I think for all of the three algorithms the input data and output location are required, so this tab now is designed for the inputs and outputs for all three algorithms
2. The "setting" tab has been changed to the setting of "region growth" since previously it only provided the setting of that algorithm.
3. Two Tabs of "shift_mean" and "watershed" were added to input the setting of each algorithm. I just give some preliminary input parameters for them, when we start coding I will give more substantial parameters required in the algorithm.
The user are supposed to give the input, output, and select which algorithm are utilized. Then define settings of that algorithm in the corresponding tab. The option tab are supposed to be additional settings. Please see attached pics for new GUI and advise if you think this setting logistic works.
}}}

== 23 - 28 May week 1: Start coding, develop pseudo code to outline the work ==

2016-05-29T17:22:00Z

Wiki-Hao2309:

User talk:Weekly report

2016-05-29T17:21:33Z

Wiki-Hao2309:

User talk:Weekly report

2016-05-29T17:17:26Z

Wiki-Hao2309:

2016-05-01T17:41:58Z

Wiki-Hao2309: /* GRASS GSoC 2016 Additional Image Segmentation for i.segment */ new section

'''Welcome to ''OSGeo Wiki''!'''
We hope you will contribute much and well.
You will probably want to read the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages].
Again, welcome and have fun! [[User:Neteler|Neteler]] ([[User talk:Neteler|talk]]) 14:50, 29 April 2016 (PDT)

== GRASS GSoC 2016 Additional Image Segmentation for i.segment ==

{| {{Prettytable}}
| The Google Summer of Code project is finished. Results and source codes are published on project web page: [http://www.klokan.cz/projects/gdal2tiles/ GDAL2Tiles: Utility for easy tile-based publishing of raster maps and KML generation]. Usage tips and manual page is available on GDAL wiki page [http://trac.osgeo.org/gdal/wiki/UserDocs/Gdal2Tiles Gdal2Tiles Utility]. Project was accepted by GDAL community as [http://trac.osgeo.org/gdal/ticket/1763 #1763]. Utility is going to be distributed with new version of GDAL 1.5.0, but it is usable also now with stable branch of GDAL and FWTools.
|}

For suggestions and new ideas please use [[Talk:GDAL2Tiles_SoC_2007]].

[[Image:Pyramid.jpg|thumb|right|286px|Pyramid Tile Structure]]
Implementation of [http://www.gdal.org/gdal_drivertut.html Raster Driver for GDAL library], which will allow to write PNG/JPG '''Pyramid Tile Structure''' as a newly supported file-format. Generated tiles will contain also XML metadata, so after putting them on any webserver they could be used as data source for:

*[http://earth.google.com/ Google Earth] (with [http://earth.google.com/kml/kml_21tutorial.html#superoverlays SuperOverlay KML])
*[http://maps.google.com/ Google Maps]
*[http://www.openlayers.org/ OpenLayers]
*[http://www.worldkit.org/ WorldKit]

and probably other viewers.

Tile structure will follow recommendation from [http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification OSGEO Tile Map Service Specification].
Simple utility 'gdal2tiles' for converting [http://www.gdal.org/formats_list.html supported file-formats] into new tile structure will be created.

Implemetation of the file format driver will allow to export map raster data into Google Earth, Google Maps and other online viewers from any of applications which use GDAL library.

Idea for this project was suggested by FrankW at [[GDAL SoC Ideas]].

== Implementation details ==

=== Abstract ===

* GRASS GIS has the i.segment which provides the possibility to segment an image into objects. This is a basic step in object-based image analysis (OBIA). Currently, the module only provides one segmentation algorithm: region-growing. The code of i.segment was structured in a way that allows addition of other algorithms. The core of proposed GSoC project would thus be to add a series of these algorithms. It would be more useful and comprehensive to add at least one or two top-down methods to the i.segment module because the current region growing approach only allows bottom-up hierarchical segmentation. New segment methods, such as mean-shift, split-window and watershed, would allow top-down hierarchical segmentation, which could be used in more types of satellite image processing. Special care should be taken for the whole project to code as efficiently as possible, i.e. to make the code run in reasonable time, even for very large images.

=== Background ===

* Image segmentation or object recognition is the process of grouping similar pixels into unique objects. Segmentation of remote sensing images is a challenging task. A myriad of different methods have been proposed and implemented in recent years. In spite of the huge effort invested in this problem, there is no single approach that can generally solve the problem of segmentation for the large variety of image modalities existing today. The most effective segmentation algorithms are obtained by carefully customizing combinations of components. The parameters of these components are tuned for the characteristics of the image modality used as input and the features of the objects to be segmented
* In the GRASS i.segment module currently only region growing and merging algorithm is implemented. Each object found during the segmentation process is given a unique ID and is a collection of contiguous pixels meeting some criteria. Note the contrast with image classification where all pixels similar to each other are assigned to the same class and do not need to be contiguous. The image segmentation results can be useful on their own, or used as a preprocessing step for image classification. The segmentation preprocessing step can reduce noise and speed up the classification

=== Segmentation Methods ===

* Command-line utility similar to existing [http://www.gdal.org/gdal_utilities.html GDAL utilities].
* Should be able to process files without proper georeference (to publish X-Ray images, vedute and other large bitmap files too).

== Possible future extension (not necessarily part of SoC project) ==

* 1. Region growing and merging (available in i.segment module )
This segmentation algorithm sequentially examines all current segments in the raster map. The similarity between the current segment and each of its neighbors is calculated according to the given distance formula. The basic approach of a region growing algorithm is to start from a seed region (typically one or more pixels) that are considered to be inside the object to be segmented. The pixels neighboring this region are evaluated to determine if they should also be considered part of the object. If so, they are merge to the region and the process continues as long as new pixels are added to the region [3].
* 2. Mean-shift (plan to be implemented during GSoC 2016)
The mean shift segmentation is a local homogenization technique that is very useful for damping shading or tonality differences in localized objects. For the algorithm implementation of this case, basically the algorithm replaces each pixel with the mean of the pixels in a range-r neighborhood and whose value is within a distance d. The Mean Shift takes usually 3 inputs: 1) A distance function for measuring distances between pixels. Usually the Euclidean distance, but any other well defined distance function could be used. The Manhattan Distance is another useful choice sometimes. 2) A radius. All pixels within this radius (measured according the above distance) will be accounted for the calculation. 3) A value difference. From all pixels inside radius r, we will take only those whose values are within this difference for calculating the mean [4].

* 3. Watershed (plan to be implemented during GSoC 2016)
Watershed segmentation classifies pixels into regions using gradient descent on image features and analysis of weak points along region boundaries. Imagine water raining onto a landscape topology and flowing with gravity to collect in low basins. The size of those basins will grow with increasing amounts of precipitation until they spill into one another, causing small basins to merge together into larger basins. Catchment basins are formed by using local geometric structure to associate points in the image domain with local extrema in some feature measurement such as curvature or gradient magnitude. The watersheds technique is also more flexible in that it does not produce a single image segmentation, but rather a hierarchy of segmentations from which a single region or set of regions can be extracted a-priori, using a threshold, or interactively, with the help of a graphical user interface.

== Schedule ==

* Preparation: Discuss with Mentors. Gather ideas from the community. Feature requests, image segmentation literature, and any other ideas and suggestions.
* 16 – 21 May week 0: Setup coding environmental, get familiar with programming manual, test through existing code.
* 23 -- 28 May week 1: Start coding, develop pseudo code to outline the work
* 30 May -- 4 June week 2: implement mean-shift image segmentation algorithm
* 6 -- 11 June week 3: Validation mean-shift algorithm
* 13 -- 18 June week 4: Debugging mean-shift algorithm
* 20 -- 26 June Week 5: Caching week, further refine and validate the code
* 27 June Mid-term evaluation: Evaluate the existing program, determine the plan for the remaining 3-4 weeks.
* 28 June -- 2 July Week 6: based on the evaluation of the mid-term, test and ensure a solid existing program.
* 4 -- 9 July Week 7: Implement watershed image segmentation algorithm
* 11 -- 16 July Week 8: Validation and debugging watershed algorithm
* 18 -- 23 July: Further refine tests and documentation for the whole project.
* 25 July – 13 August Week 9-11: Improving the main algorithm, if time permits, adding shape as an additional merge criteria,
* 15 August - 23 August Final week: Tidy code, write tests, improve documentation and submit code sample.

== Main Goal ==

Implement more image segmentation methods to extend the available i.segment for image processing in GRASS. As the general logistics of the i.segment module is in place, adding mean-shift and watershed segmentation algorithms should be possible. The core of the GSoC project thus is to add a series of these algorithms. In addition, the current implementation only uses distance within the multidimensional space of all input bands as the criteria whether to merge segments or not. Adding shape as an additional merge criteria will be helpful. If time permits, this feature of additional shape criteria will be implemented.

== Possible difficulties and solution ==

As it usually happens with software development, I might come across problems during implementation of the above mentioned ideas which may take longer than I expected, in such a case, I have kept two weeks (week 5 and week 9) as caching weeks which are intended to let me catch up on unimplemented parts of the project.
I will be working on this project full time as of now. I plan to keep in touch with my mentor as much as I can and will be reporting to him every time I am done with finishing things on my to-do list. My college semester ends on May 5. New semester starts at the middle of August and hence only about one weeks of the GSoC project would overlap with college work, this will not be a problem as there isn’t much work in the first few weeks of college. After that, I have no other obligations whatsoever and am completely free to work on the project.
If my project need more work or maintenance after the summer ends, I would love to stick around and help. I actually have an own idea and want to implement and add to the GRASS lib after the training through GSoC. Afterwards I will look at other projects and see what I’m interested in.

== Who will use results of this project ==

Several organizations and individuals who handle processing of maps.

Institutions which will use the 'gdal2tiles' utility from this project, as I am cooperating with them:
* Moravian Library in Brno, Czech Republic
* Historical institute of Czech Academy of Sciences
* Czech National Library
* National Library of Scotland
* University of Connecticut Library (with their grant [http://www.rlg.org/en/page.php?Page_ID=20522#article1 "Building a Globally Distributed Historical Sheet Map Set of Austro-Hungarian Topographic Maps, 1877-1914"], cooperating with New York Public Library, University of Connecticut Library, and Library of the American Geographical Society. It is a grant about building a scalable workflow and toolset for map libraries to add cartographic content to the Web.)

== Student's Biography ==

My name is Bo Yang, I have finished Master degree in Applied Informatics at [http://www.muni.cz/ Masaryk University in Brno], now I am in the first semester of postgraduate study of Cartography at [http://www.cvut.cz/ Czech Technical University in Prague]. My Master thesis subject was [http://is.muni.cz/th/39656/fi_m/annotation_english.txt "Processing and Digital Publishing of Historical Documents"] ([http://www.staremapy.cz/th.pdf PDF of thesis in Czech]).

I am familiar with open-source projects. I have experience with Linux/Solaris system administration. I like Python language, but I have also used other languages (C language, PHP).
I have supplied some patches into Gnumeric ([http://bugzilla.gnome.org/show_bug.cgi?id=330129 #330129], [http://bugzilla.gnome.org/show_bug.cgi?id=334257 #334257]).
I founded a http://mplayerosx.sf.net/ project and I also won a competition in programming application for Mac using http://dictosx.sf.net/ (Objective-C).
My primary desktop is Gnome and Linux, but I also use Mac, Windows and Solaris. I did programming for all of these platforms (mostly smaller projects).

I am interested in historical cartography, I have several presentations about old maps and free software. I made a czech web page about it at http://www.staremapy.cz/ and registered domain http://www.oldmapsonline.org/ (which is not in use yet).

My homepage with contact info: http://www.klokan.cz/.

[[Category:Google Summer of Code]]

GDAL2Tiles SoC 2007

2016-05-01T17:30:23Z

Wiki-Hao2309:

{| {{Prettytable}}
| The Google Summer of Code project is finished. Results and source codes are published on project web page: [http://www.klokan.cz/projects/gdal2tiles/ GDAL2Tiles: Utility for easy tile-based publishing of raster maps and KML generation]. Usage tips and manual page is available on GDAL wiki page [http://trac.osgeo.org/gdal/wiki/UserDocs/Gdal2Tiles Gdal2Tiles Utility]. Project was accepted by GDAL community as [http://trac.osgeo.org/gdal/ticket/1763 #1763]. Utility is going to be distributed with new version of GDAL 1.5.0, but it is usable also now with stable branch of GDAL and FWTools.
|}

For suggestions and new ideas please use [[Talk:GDAL2Tiles_SoC_2007]].

[[Image:Pyramid.jpg|thumb|right|286px|Pyramid Tile Structure]]
Implementation of [http://www.gdal.org/gdal_drivertut.html Raster Driver for GDAL library], which will allow to write PNG/JPG '''Pyramid Tile Structure''' as a newly supported file-format. Generated tiles will contain also XML metadata, so after putting them on any webserver they could be used as data source for:

*[http://earth.google.com/ Google Earth] (with [http://earth.google.com/kml/kml_21tutorial.html#superoverlays SuperOverlay KML])
*[http://maps.google.com/ Google Maps]
*[http://www.openlayers.org/ OpenLayers]
*[http://www.worldkit.org/ WorldKit]

and probably other viewers.

Tile structure will follow recommendation from [http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification OSGEO Tile Map Service Specification].
Simple utility 'gdal2tiles' for converting [http://www.gdal.org/formats_list.html supported file-formats] into new tile structure will be created.

Implemetation of the file format driver will allow to export map raster data into Google Earth, Google Maps and other online viewers from any of applications which use GDAL library.

Idea for this project was suggested by FrankW at [[GDAL SoC Ideas]].

== Implementation details ==

=== Pyramid Tile Structure and Metadata ===

* Metadata from [http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification TMS Specification] will be created as a main source of georeference (especially [http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification#TileMap_Resource TileMap Resource XML]).
* KML supports only EPSG:4326 (latlong with WGS84 datum) projection, so reprojection is needed if source projection is different. How to turn off unneeded tiles by Regions in KML?
* It would be nice to support zoom levels of Google Maps tiles (this have to be checked, maybe from [http://mapnik.org/ Mapnik] project, example of [http://mapnik.org/tiling/oxford/ generated tiles]. More info is available here: http://michal.guerquin.com/googlemaps.html and http://docs.codehaus.org/display/GEOSDOC/Google+Maps

=== GDAL Driver ===

* implements Create() function, so random access to format is possible (so for example direct warping of image into tiles will run).

=== GDAL2Tiles utility ===

* Command-line utility similar to existing [http://www.gdal.org/gdal_utilities.html GDAL utilities].
* Should be able to process files without proper georeference (to publish X-Ray images, vedute and other large bitmap files too).

== Possible future extension (not necessarily part of SoC project) ==

* Support for [http://dev.live.com/virtualearth/sdk/ Microsoft Virtual Earth] - they have generator [http://research.microsoft.com/mapcruncher/ MapCruncher]
* Support for [http://worldwind.arc.nasa.gov/ NASA World Wind]. Tile generation for [http://www.worldwindcentral.com World Wind] is done via GDAL using the dstile utility available [http://www.worldwindcentral.com/wiki/Dstile_howto here]. Source code is [http://www.worldwindcentral.com/wiki/Making_Layers here]. Does it have only fixed internal structure of tiles or tile structure (names of directories and png files) could be done by TMS recomendation?
* Maybe support of [http://www.ossim.org/OSSIM/ossimPlanet.html OSSIM Planet].
* Simple GUI for 'gdal2tiles' under Windows/Linux/Mac done with Python (one of WxWidgets/TKinter/EasyDialogs).
* Implementation of GDAL Reader for generated tile structure (could be based on [https://svn.osgeo.org/svn/gdal/trunk/gdal/frmts/wcs/ gdal/frmts/wcs], thanks FrankW)
* [http://www.staremapy.cz/zoomify-analyza/ Zoomify Tile Structure] as alternative or modification of Zoomify with support for generated structure
* Maybe implementation of georeference for tilestructure by use of GML.

== Schedule ==

* May 28: Designing the file format, XML Metadata formats(KML, TMS XML files, MS Virtual Earth, ...?) which will be supported have to be chosen and tested with their respective viewer applications, sample map is published.
* July 9: Alfa version of GDAL Driver for Tile Structure Writer is uploaded into official SVN.
* August 20: Final version of the driver as well as gdal2tiles utility are uploaded and reviewed.

== Competitors ==

Proprietary applications like: [http://www.arc2earth.com/ Arc2Earth] have similar functionality. Several (mostly proprietary) generators for Google Earth tiles were mentioned on http://www.ogleearth.com/.

Microsoft Research project [http://research.microsoft.com/mapcruncher/ MapCruncher] also generates tiles, but with metadata only for their MS Virtual Earth.

[http://www.zoomify.com/ Zoomify] could be now used as tiling program for SuperOverlay in GoogleEarth with free [http://www.zoomify.com/express.htm ZoomifyerEZ] and generator [http://www.staremapy.cz/zoomifykml/ ZoomifyKML] (which I created as a part of my Master Thesis).

== What new functionality this project brings ==

Clean open-source implementation of tile structure export. Any application which uses GDAL library will easily be able to export files into a tile structure. Supplied utility gdal2tiles will convert [http://www.gdal.org/formats_list.html any supported file format] with georeference into tiles, it will also allow batch mode processing of files.

GDAL is strong library for processing maps and large raster files, including reprojection, so any already georeferenced maps could be easily converted for simple on-line publishing on a webserver without special server requirements (like MapServer is). Advantages of this approach are described in [http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification TMS Specification].

Reader could be implemented later, which will (with support on the side of UNM MapServer) allow to access published tile structure using WMS standard, where UNM MapServer will act as a proxy.

== Who will use results of this project ==

Several organizations and individuals who handle processing of maps.

Institutions which will use the 'gdal2tiles' utility from this project, as I am cooperating with them:
* Moravian Library in Brno, Czech Republic
* Historical institute of Czech Academy of Sciences
* Czech National Library
* National Library of Scotland
* University of Connecticut Library (with their grant [http://www.rlg.org/en/page.php?Page_ID=20522#article1 "Building a Globally Distributed Historical Sheet Map Set of Austro-Hungarian Topographic Maps, 1877-1914"], cooperating with New York Public Library, University of Connecticut Library, and Library of the American Geographical Society. It is a grant about building a scalable workflow and toolset for map libraries to add cartographic content to the Web.)

== Student's Biography ==

My name is Klokan Petr Přidal, I have finished Master degree in Applied Informatics at [http://www.muni.cz/ Masaryk University in Brno], now I am in the first semester of postgraduate study of Cartography at [http://www.cvut.cz/ Czech Technical University in Prague]. My Master thesis subject was [http://is.muni.cz/th/39656/fi_m/annotation_english.txt "Processing and Digital Publishing of Historical Documents"] ([http://www.staremapy.cz/th.pdf PDF of thesis in Czech]).

I am familiar with open-source projects. I have experience with Linux/Solaris system administration. I like Python language, but I have also used other languages (C language, PHP).
I have supplied some patches into Gnumeric ([http://bugzilla.gnome.org/show_bug.cgi?id=330129 #330129], [http://bugzilla.gnome.org/show_bug.cgi?id=334257 #334257]).
I founded a http://mplayerosx.sf.net/ project and I also won a competition in programming application for Mac using http://dictosx.sf.net/ (Objective-C).
My primary desktop is Gnome and Linux, but I also use Mac, Windows and Solaris. I did programming for all of these platforms (mostly smaller projects).

I am interested in historical cartography, I have several presentations about old maps and free software. I made a czech web page about it at http://www.staremapy.cz/ and registered domain http://www.oldmapsonline.org/ (which is not in use yet).

[[Category:Google Summer of Code]]