FOSS4G In Large-scale Projects
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Turkovic, Marko (IGEA ltd.)
Bremec, Igor (IN2 Ltd.)
Obad, Tomislav (Igea Ltd.)
The presentation covers experiences and challenges encountered during the implementation of the Kosovo Spatial Data Infrastructure. The SDI consists of GeoPortal, Cadaster and Land Information System and the Address Register, all implemented on the FOSS stack and interconnected via OGC services.
 Thank you, Alex. Can you all hear me? Those in the back? Is this okay? Can you speak up a little bit? Yeah. Okay. Now, can everybody hear me in the back? Is it okay? Okay. I won't use the microphone. Okay. Welcome to today's talk. I'm Marco Turkovich. I work as a developer in I-GIA from Croatia. It's part of IN2 group. I won't bother you too much with the numbers, but we are the largest software development company in Croatia. We have offices across Eastern and South Europe. And maybe to say that I-GIA is a competent center for GIS. So we do a GIS development. Today's presentation and a solution is part of Kosovo Cadestral Agency spatial data infrastructure that we have implemented recently. It is an ongoing project, so we have about two or three months of development left. It is an integrated Web GIS solution for spatial data definition and maintenance. And it consists of several functional software modules that were separate projects, a geoportal, cadastral and land information system, and address registry for address data, maintenance and definition. One of the specialties of this project was that we were forced to use Microsoft software for a database management system and for operational system because of contract of Republic of Kosovo and Microsoft. So we couldn't choose that, of course. If we could, we would go with Post-GIS, but that was not a question. And the other thing that modules that would be developed in this project would facilitate the next big software projects that we are part of. So this diagram shows the component architecture of the whole system. So from the user's perspective, we have a geoportal as a data dissemination point. You will recognize a couple of those logos there. We use that all. So this down there is an internal system. It's an internet application for KCA users where they define and maintain the data. This module deals with address register data, and this module deals with cadastral data. So this is the central part of the whole system. It offers viewing and editing capabilities for the data. So that's the point of the system that consumed most of our development time. This is the short overview of a KCLS graphical component. We call it KG, of course. It's integrated solution for definition and maintenance of KCA's data space. Spatial data sets, both address register and cadastral. And it's a basis for development of other modules that would work with other KCA information system. Of course, we use the geoportal to disseminate the data toward the public. Its architecture is a classical three tier architecture. On a database level, we have SQL Server 2008. On the middle tier, we have Geo Server with Geo Webcache and.NET MVC3 business application. Client side is developed in open layers, GeoXt and XJS, standard solution. And the components, of course, base to SOAP principles communicate via services, WMS and WFS and JSON. Couple of functions that our KG application offers. It's, of course, the main component is a viewer editor. It's the main point for the spatial data viewing and editing, then the feature class tool that enables us to define other feature classes and import data into our system later. It rests on Geo Server Rests up before publishing new feature classes on Geo Server once they are collected. Then we have import tool that we use for importing the data into our system. Currently, we support GML shape, DWG, Interlis and GeoT for Raster data. And then there is styling tool which we use to dynamically style our geometries on a client side. It's client side. This is a short GeoPortal overview. Of course, as I said before, this is a central public oriented software for dissemination of spatial data sets. And you can see the user interface here on this picture. This is architecture of GeoPortal. It's very similar to KG application, except you will notice we have LIFRE portal enterprise here that wraps client side functionality and access proxy on middle layer for proxying WFS and JSON requests to business application. GeoPortal enables us to view spatial and related open numeric data. It offers search and discovery services, ordering and download of data sets and product, and upload of data sets by data providers and enables users to give feedback on data quality so that can be checked. This is the URL for GeoPortal, so check it out. So the next part of the presentation is about challenges that we have met during the development process. I have listed 308 challenges, so we'll go one by one until the end. So I better hurry. The first challenge that we knew it will be a big problem. This is a very bad joke. So it's OK. If you're not laughing, it's called bad joke yield. We had to make a tool for curve digitization. So what we did, we implemented quadratic curve handler, so that's open-air development based on quadratic-bezier curve parametric equation. So we, in the end, approximated with line geometry, and this is how it works in practice. So you digitize the first point, the last point, and then you use the apex to reshape the curve. This is the next cool handler that we did. This is a line curve-curve-switcher handler that enables us to seamlessly switch between arc digitization and linear segment digitization. So it enables fast digitizing. This is 4G. OK. So when it comes to polygons digitization, we also implemented several cool features. We basically, what we did, of course, was to extend open-layers draw feature control. We used JSTS on a client side for geometry validity and topology checks and pull operations. So the first tool that I will show you is a polygon splitting tool. The second is a remove polygon area, and then adjacent polygon digitization. So this is a demonstration of polygon splitting tool. It's a done client side, so it uses JSTS for splitting the polygon. And we can see here the one multipolygon has appeared in this configuration. It supports polygons with holes, so it's quite cool. And it's done client side. This is a tool that we can use to draw multipolygons on a client side with open-layers. So we just add geometry while tool is active, and it will add to existing geometry. We can also subtract the geometry from a polygon and get a cool-looking robot. This is a very cool feature. It's inspired on the GIS software. And what we have here is a first polygon, and then we digitize a line around it, and it just finishes a polygon automatically to close the minimal surface with the first polygon. You get the idea. These are cat-like tools for perpendicular and parallel construction. What they do first is they segment the line from point to point so that perpendicular and parallel construction would even make sense. Then when we select the segment that we want, they just programmatically draw a parallel and perpendicular line, and then you can reshape it by dragging. This is a nice example of a tool that guides the user how to use the application. It has five steps. So basically, what we want to do is to digitize a point that lines on an intersection of a circle and a line. So what user does first is digitizes start point of the line, end point of the line, center of the circle, enters radius, and then selects the appropriate point that he wants to use. This is a very cool feature. It's topology preserving modify feature. It's basically extended modify feature, promote layers, and what it does is when we drag a point that coincides with other points, that point goes with it as well. So the topology of our section is preserved. It also has a validity check. We don't allow self-intersecting polygons, and it has a rollback. So when we do an error on geometry, it just fixes itself to the last valid state. As you can see, I think it resides on a JSTS for all the operations. It could use some modifications like insert of tool that would insert vertex on all coincident geometries and delete tool, but that's a work in progress. OK. Basically, our application is a full-featured web editing application. And we knew we will have performance issues when we decided to use open layers, because the large number of features will always overburden the browser. It has limited capabilities, limited memory, so we had to think of something that would be useful for us. Something that would ease this up. So what we did was to extend open layer strategy bounding box so that it implements seamless switching between vector and WMS layers based on a zoom level. So on a large scale, you have vector features, and on a small scale, when you zoom out, you have WMS features. So that means that you can draw on the full extent, but you can select anything. So if you want to select features, you zoom in to 1 to 5,000 or whatever you want, whatever you set it. And then you can select the edit data and the data that is edited and selected that doesn't get uploaded when you zoom out again. So it's a pretty cool feature. And the bounding box does everything, keeps track of the WMS layer, so you don't have to worry about anything. Of course, this is this actual concept is inspired by edit session on desktop GIS tools. And what we did was implemented one set of controls that can work on all layers. So we don't have to duplicate controls. What was missing in Opal layers that to work out of the box was that some controls don't have implemented set layer. So we added set layer method for every control that we use. And then when user activates edit session for some layer, all controls get rewired to that layer, so they can work on it. One of the requirements of Project was to enable user to dynamically style vector and WMS layers, so to be able to change the styling information about everything. So for this, we used the Geosolutions style editor component. And what we do is when a user edits the SLD, through the graphical interface, we create a new layer. Through the graphical interface, we create vector styles from that SLD, dynamically reload the icons for each layer node in the layer tree. And besides that, we have also overridden OpenLayer Surrender and OpenLayer Format SLD classes to add support for label rotation, which we needed as well. Multilingual support was a big issue for us. We implemented in several layers in the application. On client side, we have I18n language files for JavaScript. And then in the database, we have multiple attributes for each language. We have an attribute in the database. But how to style geometries? We asked Geosolutions to develop a new function for that cause. It uses a variable and substitution. And it's called property. And you can send in request the name of the attribute that you want to use for geometry styling. That's pretty cool. It's a very serious and official system. So of course, we had a lot of demands on spatial data quality control. We have a set of business rules and data naming convention that we have to follow. And of course, we check geometry validity on the client side, that performance is OK. So it's good. But for several others, complicated topology and special layer-to-layer topology checks and hierarchy checks that form hierarchy, we use the database spatial data quality control via procedures and such. On the middle tier, we use JTS port and NTS for several other checks. So we could say we have a three-way quality control on our system. So because you remember the graph from before, all those systems are interconnected. And so as the Geoportals disseminates the data for internal applications, we don't want to overburden our internal infrastructure with public access. So what we did was to replicate the database and GeoServer catalog from one system to another. For that, we used Microsoft SQL server integration services and GeoServer raced up before reconfiguration of data stores when we moved them from one storage to another. I think this is the last one. So bear with me. Of course, as I mentioned in the start, we had to use Microsoft software for operating system and for DBMS. And also, we use an application server for Microsoft IS 7 and the.NET framework for and.NET MVC 3 for our business application. And for Geoportals, we use a LifeRay portal at Enterprise platform. And it wraps our client-side functions in portlets. So that was one of the. OK, so we have plans for improvement of that system. The development of the Cadaster component is still in progress, so it's an ongoing project about a couple of months more, and it will be over. Then we thought it would be cool to offer some kind of a data preview when importing our data, but that still needs to do something. More flexible language and security would be nice also for application. Which security, especially. And then the native support for curve geometries from GeoServer and JTS and Geotools and OpenLayers that would probably need a tremendous amount of time and effort from the community to be implemented. But I'm sure it will be implemented one day. So of course, it is our duty, and we would be very nice that we try to contribute more to the open source community. So in the end of the project, we'll contact some of the developers from OpenLayers and see if there's any interest in modules that we have developed for this application. So in the end, to wrap things up, we have learned that Phos4G is mature enough and flexible enough to implement very complex SDI implementations and business applications. So of course, the Big Plus is a great community, very large community that helped us in every way that it could. In the process of development, the software is very versatile, flexible, scalable, all the nice things. And even if we want to, we can easily integrate it with proprietary software as we had to do. Of course, we can only conclude that it was the right choice for this particular project and implementation. OK, so that's it from me. I think we have enough time. Thank you. So feel free to ask something. Yes, sir? We've got five minutes for questions. Hi, I'm Mark. Very good talk, honestly. Thank you. And I'm a part of the OpenLayers. So I'm very...
 Thank you, Alex. Can you all hear me?  Those in the back? Is this okay?  Can you speak up a little bit?  Yeah. Okay. Now, can everybody hear me in the back?  Is it okay? Okay.  I won't use the microphone.  Okay. Welcome to today's talk.  I'm Marco Turkovich.  I work as a developer in I-GIA from Croatia.  It's part of IN2 group.  I won't bother you too much with the numbers,  but we are the largest software development company in  Croatia. We have offices across Eastern and South Europe.  And maybe to say that I-GIA is a competent center for GIS.  So we do a GIS development.  Today's presentation and a solution is part of  Kosovo Cadestral Agency spatial data infrastructure  that we have implemented recently.  It is an ongoing project, so we have about two or three  months of development left.  It is an integrated Web GIS solution for spatial data  definition and maintenance.  And it consists of several functional software modules  that were separate projects, a geoportal,  cadastral and land information system,  and address registry for address data,  maintenance and definition.  One of the specialties of this project was that we were  forced to use Microsoft software for a database  management system and for operational system because of  contract of Republic of Kosovo and Microsoft.  So we couldn't choose that, of course.  If we could, we would go with Post-GIS, but that was not  a question.  And the other thing that modules that would be  developed in this project would facilitate the next big  software projects that we are part of.  So this diagram shows the component architecture of  the whole system.  So from the user's perspective, we have a geoportal as a  data dissemination point.  You will recognize a couple of those logos there.  We use that all.  So this down there is an internal system.  It's an internet application for KCA users where they  define and maintain the data.  This module deals with address register data, and this  module deals with cadastral data.  So this is the central part of the whole system.  It offers viewing and editing capabilities for the data.  So that's the point of the system that consumed most of  our development time.  This is the short overview of a KCLS graphical component.  We call it KG, of course.  It's integrated solution for definition and maintenance of  KCA's data space.  Spatial data sets, both address register and cadastral.  And it's a basis for development of other modules  that would work with other KCA information system.  Of course, we use the geoportal to disseminate the data  toward the public.  Its architecture is a classical three tier architecture.  On a database level, we have SQL Server 2008.  On the middle tier, we have Geo Server with Geo Webcache and .NET MVC3 business application.  Client side is developed in open layers, GeoXt and XJS,  standard solution.  And the components, of course, base to SOAP principles  communicate via services, WMS and WFS and JSON.  Couple of functions that our KG application offers.  It's, of course, the main component is a viewer editor.  It's the main point for the spatial data viewing and  editing, then the feature class tool that enables us to  define other feature classes and import data into our  system later.  It rests on Geo Server Rests up before publishing new  feature classes on Geo Server once they are collected.  Then we have import tool that we use for importing the data  into our system.  Currently, we support GML shape, DWG, Interlis and GeoT  for Raster data.  And then there is styling tool which we use to dynamically  style our geometries on a client side.  It's client side.  This is a short GeoPortal overview.  Of course, as I said before, this is a central public  oriented software for dissemination of spatial  data sets.  And you can see the user interface here on this  picture.  This is architecture of GeoPortal.  It's very similar to KG application, except you will  notice we have LIFRE portal enterprise here that wraps  client side functionality and access proxy on middle layer  for proxying WFS and JSON requests to business application.  GeoPortal enables us to view spatial and related  open numeric data.  It offers search and discovery services, ordering and  download of data sets and product, and upload of data  sets by data providers and enables users to give feedback  on data quality so that can be checked.  This is the URL for GeoPortal, so check it out.  So the next part of the presentation is about  challenges that we have met during the development  process.  I have listed 308 challenges, so we'll go one by one  until the end.  So I better hurry.  The first challenge that we knew it will be a big problem.  This is a very bad joke.  So it's OK.  If you're not laughing, it's called bad joke yield.  We had to make a tool for curve digitization.  So what we did, we implemented quadratic curve  handler, so that's open-air development based on  quadratic-bezier curve parametric equation.  So we, in the end, approximated with line geometry,  and this is how it works in practice.  So you digitize the first point, the last point, and then  you use the apex to reshape the curve.  This is the next cool handler that we did.  This is a line curve-curve-switcher handler that  enables us to seamlessly switch between arc digitization  and linear segment digitization.  So it enables fast digitizing.  This is 4G.  OK.  So when it comes to polygons digitization,  we also implemented several cool features.  We basically, what we did, of course,  was to extend open-layers draw feature control.  We used JSTS on a client side for geometry validity  and topology checks and pull operations.  So the first tool that I will show you  is a polygon splitting tool.  The second is a remove polygon area, and then  adjacent polygon digitization.  So this is a demonstration of polygon splitting tool.  It's a done client side, so it uses JSTS  for splitting the polygon.  And we can see here the one multipolygon  has appeared in this configuration.  It supports polygons with holes, so it's quite cool.  And it's done client side.  This is a tool that we can use to draw multipolygons on a client  side with open-layers.  So we just add geometry while tool is active,  and it will add to existing geometry.  We can also subtract the geometry from a polygon  and get a cool-looking robot.  This is a very cool feature.  It's inspired on the GIS software.  And what we have here is a first polygon,  and then we digitize a line around it,  and it just finishes a polygon automatically  to close the minimal surface with the first polygon.  You get the idea.  These are cat-like tools for perpendicular and parallel  construction.  What they do first is they segment the line from point  to point so that perpendicular and parallel construction  would even make sense.  Then when we select the segment that we want,  they just programmatically draw a parallel and perpendicular  line, and then you can reshape it by dragging.  This is a nice example of a tool that guides the user how  to use the application.  It has five steps.  So basically, what we want to do is to digitize a point that  lines on an intersection of a circle and a line.  So what user does first is digitizes start point of the  line, end point of the line, center of the circle,  enters radius, and then selects the appropriate point  that he wants to use.  This is a very cool feature.  It's topology preserving modify feature.  It's basically extended modify feature, promote layers,  and what it does is when we drag a point that coincides  with other points, that point goes with it as well.  So the topology of our section is preserved.  It also has a validity check.  We don't allow self-intersecting polygons, and  it has a rollback.  So when we do an error on geometry, it just fixes itself  to the last valid state.  As you can see, I think it resides on a JSTS for all  the operations.  It could use some modifications like insert of tool that  would insert vertex on all coincident geometries and  delete tool, but that's a work in progress.  OK.  Basically, our application is a full-featured web editing  application.  And we knew we will have performance issues when we  decided to use open layers, because the large number of  features will always overburden the browser.  It has limited capabilities, limited memory, so we had to  think of something that would be useful for us.  Something that would ease this up.  So what we did was to extend open layer strategy bounding  box so that it implements seamless switching between  vector and WMS layers based on a zoom level.  So on a large scale, you have vector features, and on a  small scale, when you zoom out, you have WMS features.  So that means that you can draw on the full extent, but you  can select anything.  So if you want to select features, you zoom in to 1  to 5,000 or whatever you want, whatever you set it.  And then you can select the edit data and the data that is  edited and selected that doesn't get uploaded when you  zoom out again.  So it's a pretty cool feature.  And the bounding box does everything, keeps track of  the WMS layer, so you don't have to worry about anything.  Of course, this is this actual concept is inspired by edit  session on desktop GIS tools.  And what we did was implemented one set of controls  that can work on all layers.  So we don't have to duplicate controls.  What was missing in Opal layers that to work out of the box  was that some controls don't have implemented set layer.  So we added set layer method for every control that we use.  And then when user activates edit session for some layer, all  controls get rewired to that layer, so they can work on it.  One of the requirements of Project was to enable user to  dynamically style vector and WMS layers, so to be able to  change the styling information about everything.  So for this, we used the Geosolutions style editor  component.  And what we do is when a user edits the SLD, through the  graphical interface, we create a new layer.  Through the graphical interface, we create vector styles  from that SLD, dynamically reload the icons for each layer  node in the layer tree.  And besides that, we have also overridden OpenLayer  Surrender and OpenLayer Format SLD classes to add support for  label rotation, which we needed as well.  Multilingual support was a big issue for us.  We implemented in several layers in the application.  On client side, we have I18n language files for JavaScript.  And then in the database, we have multiple attributes for  each language.  We have an attribute in the database.  But how to style geometries?  We asked Geosolutions to develop a new function for that  cause.  It uses a variable and substitution.  And it's called property.  And you can send in request the name of the attribute that  you want to use for geometry styling.  That's pretty cool.  It's a very serious and official system.  So of course, we had a lot of demands on spatial data  quality control.  We have a set of business rules and data naming convention  that we have to follow.  And of course, we check geometry validity on the client  side, that performance is OK.  So it's good.  But for several others, complicated topology and  special layer-to-layer topology checks and hierarchy  checks that form hierarchy, we use the database spatial  data quality control via procedures and such.  On the middle tier, we use JTS port and NTS for several  other checks.  So we could say we have a three-way  quality control on our system.  So because you remember the graph from before, all those  systems are interconnected.  And so as the Geoportals disseminates the data for  internal applications, we don't want to overburden our  internal infrastructure with public access.  So what we did was to replicate the database and  GeoServer catalog from one system to another.  For that, we used Microsoft SQL server integration  services and GeoServer raced up before reconfiguration of  data stores when we moved them from one storage to another.  I think this is the last one.  So bear with me.  Of course, as I mentioned in the start, we had to use  Microsoft software for operating system and for  DBMS.  And also, we use an application server for  Microsoft IS 7 and the.NET framework for and.NET MVC 3  for our business application.  And for Geoportals, we use a LifeRay portal at  Enterprise platform.  And it wraps our client-side functions in  portlets.  So that was one of the.  OK, so we have plans for improvement of that system.  The development of the Cadaster component is still in  progress, so it's an ongoing project about a couple of  months more, and it will be over.  Then we thought it would be cool to offer some kind of a  data preview when importing our data, but that still needs  to do something.  More flexible language and security would be nice also  for application.  Which security, especially.  And then the native support for curve geometries from  GeoServer and JTS and Geotools and OpenLayers that  would probably need a tremendous amount of time and  effort from the community to be implemented.  But I'm sure it will be implemented one day.  So of course, it is our duty, and we would be very  nice that we try to contribute more to the open source  community.  So in the end of the project, we'll contact some of the  developers from OpenLayers and see if there's any interest  in modules that we have developed for this application.  So in the end, to wrap things up, we have learned that  Phos4G is mature enough and flexible enough to implement  very complex SDI implementations and business  applications.  So of course, the Big Plus is a great community, very  large community that helped us in every way that it could.  In the process of development, the software is very versatile,  flexible, scalable, all the nice things.  And even if we want to, we can easily integrate it with  proprietary software as we had to do.  Of course, we can only conclude that it was the right  choice for this particular project and implementation.  OK, so that's it from me.  I think we have enough time.  Thank you.  So feel free to ask something.  Yes, sir?  We've got five minutes for questions.  Hi, I'm Mark.  Very good talk, honestly.  Thank you.  And I'm a part of the OpenLayers.  So I'm very...
FOSS4G_In_Large-scale_Projects__720p__0_1115.png FOSS4G_In_Large-scale_Projects__720p__1116_3203.png FOSS4G_In_Large-scale_Projects__720p__3204_4811.png FOSS4G_In_Large-scale_Projects__720p__4812_5831.png FOSS4G_In_Large-scale_Projects__720p__5832_6623.png FOSS4G_In_Large-scale_Projects__720p__6624_8099.png FOSS4G_In_Large-scale_Projects__720p__8100_8495.png FOSS4G_In_Large-scale_Projects__720p__8496_9011.png FOSS4G_In_Large-scale_Projects__720p__9012_9767.png FOSS4G_In_Large-scale_Projects__720p__9768_10223.png FOSS4G_In_Large-scale_Projects__720p__10224_10451.png FOSS4G_In_Large-scale_Projects__720p__10452_10499.png FOSS4G_In_Large-scale_Projects__720p__10500_11231.png FOSS4G_In_Large-scale_Projects__720p__11232_11843.png FOSS4G_In_Large-scale_Projects__720p__11844_12683.png FOSS4G_In_Large-scale_Projects__720p__12684_13343.png FOSS4G_In_Large-scale_Projects__720p__13344_13871.png FOSS4G_In_Large-scale_Projects__720p__13872_14591.png FOSS4G_In_Large-scale_Projects__720p__14592_15347.png FOSS4G_In_Large-scale_Projects__720p__15348_16283.png FOSS4G_In_Large-scale_Projects__720p__16284_16679.png FOSS4G_In_Large-scale_Projects__720p__16680_17963.png FOSS4G_In_Large-scale_Projects__720p__17964_18659.png FOSS4G_In_Large-scale_Projects__720p__18660_20207.png FOSS4G_In_Large-scale_Projects__720p__20208_20483.png FOSS4G_In_Large-scale_Projects__720p__20484_21359.png FOSS4G_In_Large-scale_Projects__720p__21360_21707.png FOSS4G_In_Large-scale_Projects__720p__21708_22559.png FOSS4G_In_Large-scale_Projects__720p__22560_22871.png FOSS4G_In_Large-scale_Projects__720p__22872_23999.png FOSS4G_In_Large-scale_Projects__720p__24000_26615.png FOSS4G_In_Large-scale_Projects__720p__26616_26987.png FOSS4G_In_Large-scale_Projects__720p__26988_27767.png FOSS4G_In_Large-scale_Projects__720p__27768_31031.png FOSS4G_In_Large-scale_Projects__720p__31032_31691.png