GeoTools, GeoServer, GeoGit: A Case Study of Use in Utility Field Work
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 188 | |
| Author | ||
| License | CC Attribution 3.0 Germany: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/31737 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Producer | ||
| Production Year | 2014 | |
| Production Place | Portland, Oregon, United States of America |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
00:00
Client (computing)Text editorExtension (kinesiology)Level (video gaming)Projective planeConnectivity (graph theory)Java appletPoint (geometry)View (database)Set (mathematics)Overhead (computing)Term (mathematics)DemosceneComputer configurationExpert systemCollaborationismLimit (category theory)Software developerMultiplication signCommitment schemeProcess (computing)Source codeComputer programmingCartesian coordinate systemOpen sourceDifferent (Kate Ryan album)Computer virusCASE <Informatik>Internet service providerField (computer science)Revision controlMultiplicationProduct (business)Right angleMereologyAbstractionFlow separationQuicksortComplex (psychology)Utility softwareComputing platformBitState of matterTwitterService (economics)BlogError messageStudent's t-testReal numberFunctional (mathematics)Mobile WebOffice suiteINTEGRALVariety (linguistics)AdditionDatabaseDisk read-and-write headSoftware protection dongleAttribute grammarSystem administratorPlanningPlug-in (computing)1 (number)Observational studyArray data structureFeedbackLaptopPresentation of a groupDependent and independent variablesSoftware testingSoftware maintenanceProof theoryCellular automatonSensitivity analysisWeb 2.0Machine visionSuite (music)WebsiteServer (computing)Form (programming)Casting (performing arts)Instance (computer science)VotingArc (geometry)Sinc functionVideoconferencingGeometryAreaRow (database)Regulator geneLogicWeb pageShape (magazine)Computer fileComputer animation
Transcript: English(auto-generated)
00:00
All right, I think it's about 10 o'clock, so let's get the show on the road. My name is Peter Hansen. I work for the Geographical Information Center at California State University, Chico. I have a presentation called GeoTools, GeoServer, GeoGig, a Case Study of Use in Utility Fieldwork.
00:24
It was called GeoGit, now it's called GeoGig. Kind of same difference, just a new name. At the GIC, we have kind of a dual mission to provide. It's both academic and service oriented, and we provide opportunities for the students
00:43
at Chico State to work in a GIS professional office and get experience that way. And we also provide GIS services to a variety of state agencies in terms of data development and services,
01:02
as well as folks in our local region, so some cities and municipalities. And one of those clients that we work with is the Butte County Mosquito and Vector Control District. For those of you who aren't familiar with the duties of mosquito and vector control,
01:24
their intention is to maintain and suppress mosquitoes and other kind of vector nuisances in various ways, which I'm not incredibly familiar with, because that's a whole different industry and science.
01:43
But the point here is that they have field crews that go out and they collect data. And they needed a way to collect data and view data and edit that data in a better fashion than kind of what
02:03
they were doing before, which was something that I'm sure, as GIS people, you've all come across, where they're doing it in a paper setting. So additionally, that data that they collected needed to be versionable, and they needed to have a history.
02:24
So when they went to a source point of a big pool of mosquitoes, they wanted to see what was going on there in the years prior. So it was important that they could see back to what had been done before and what the history of that site was.
02:44
So we had our initial application that we built was on Esri, and it worked, and it works, and they use it. But it obviously came at a cost.
03:03
And that cost made it difficult to bring this sort of program to other districts in any industry, really. So while that was always handy and worked out,
03:21
it just comes at a cost. So we had an intention to find an alternate solution that provided the same functionality of the product that we had initially built for them. So we climbed a ladder to this guy and we looked at open source options.
03:44
And this is kind of preaching to the choir, but obviously, there's a lower cost of entry for open source. There is an initial time and therefore money commitment
04:00
to finding stuff out, kind of a discovery process. But we knew that the tools that open source provided were commensurate and in some ways could exceed what the Esri stack provided for us. So there were additional benefits
04:20
that were kind of for our shop. Since we were using the Esri ArcGIS mobile SDK, we were already extending that with some custom programming. So we were already making that time commitment to kind of creating a custom deal for our client.
04:43
It allowed us to have a tool now that we could bring to other places without that cost. And in more of an open source sense, it allowed us to be involved in the community, to explore, to share what our findings were,
05:02
to get involved, come places like this and hear what people have to say and present our findings. So the proposed stack that we went with was a PostGIS extension with a GeoServer, a GeoTools
05:25
application on top of that, and using GeoGig for kind of the versioning and the history. Since we already had that existing application basically
05:40
pulled out that data in shapefiles, dumped it into the database, connected to GeoServer. GeoServer allowed us to feed kind of base data, which acted as the base map for the GeoTools application.
06:02
Those three projects are all very mature, very stable. I don't think I need to go into a ton of detail on how those three components came up, and definitely on the GeoTools one because I wasn't the Java developer that did that. So that fella, there's a lot of documentation
06:27
on GeoTools development. So what we created was an application that could read all the same data that we were seeing before. They could query it. They could manipulate it, zoom in, zoom out, pan,
06:45
custom forms, all the things that they were able to do before. So where we're at is kind of right there. We have the application that's kind of doing that.
07:01
We're stuck on that versioning part. That has proved to be more difficult than we anticipated. So when we wrote this abstract several months ago, it's like, yeah, we'll have that versioning bit done by then, but it's still kind of a thorn in the side.
07:21
So some things worked, and some things did not work. So in kind of typical open source fashion, you go back and look at what other tools are out there. So the database, loading that works, feeding out data, that works.
07:42
The application, like I mentioned, you can do all those things. What I've seen here in the past couple of days even is questioning that use of GeoGig, whether, in this particular instance, if it is providing almost too much complexity
08:03
for the application that we need it for. So in an interim, even before we got to this conference here, we were kind of doing this bastardized version of various states of shapefile. Our client was not a complex enough use case
08:23
to where we really needed to go into this real deep versioned editing. There's only 15 or so guys in the field. They were never overlapping areas. So the check-in, check-out process was not as complex as it needed to be.
08:42
But that's not always going to be the case for other utility agencies or the like. So I've seen now several uses that talks
09:01
I've gone to the past couple of days of people using the GitHub IOPages with the GeoJSON support. And that seems like a real viable option. And there may be a lack of understanding on my part
09:20
about why that GeoGig platform needs to exist when the GitHub platform is kind of doing the same thing kind of all on its own. So if anybody has that knowledge, I'd love to talk to you guys about it.
09:40
But given that this kind of newer solution is, we haven't really worked with it. I have an idea of how it's going to work in my head. And I'll work on that when I get back to the office. But if you guys are looking back on videos, check out Landon Reed's discussion.
10:03
He's a guy that works for the Atlanta Regional Commission. And they were using this for versioning and kind of, in a way, kind of like a crowdsourcing of data editing for roads in the Atlanta region.
10:25
So that's a real complex data set. A lot of features, a lot of attributes. And it's allowed for people to pull and push data and manipulate it and let it be reconciled by the administrators.
10:42
So in this case, where we would use this is probably pulling that GeoJSON down, pushing it into GeoTools, manipulating it there, and then pushing it back up for it to be reconciled with kind of the master database.
11:02
So there's future work to be done on the app, obviously. And one of those things is to incorporate that technique and see how it goes and report back to the community and what we found out.
11:20
We'd also like to improve the UI and the SLDs. I don't know how many folks here have worked with SLDs, but they are kind of a slog. And they're a bit difficult to work with. So improving that cartography is
11:40
something that's very important for the field crew. You can incorporate a GPS dongle onto the field laptops that they're using so they can utilize that when they're out in the field rather than having to pick a point on the map. And then, of course, we need to test it and debug it
12:00
and test and debug it and get that feedback and really flesh out that product for them. And for us as a shop and being involved in the open source community, we have a responsibility to become more involved.
12:24
And I've been kind of dabbling in various facets of open source GIS for several years. And coming to this conference, you see a lot of the names you recognize,
12:41
but then there's a whole host of other people that are doing amazing things. And they're putting things out there. So we have a need to go and discover more. And there's a ton of stuff on Twitter and there's a ton of blogs. Obviously, a lot of stuff is being shared on GitHub.
13:00
So I have met also a lot of people that are not really noobs in this kind of open source GIS. So there's a ton of stuff out there. So go and find it. Go and look at it. And then contribute more. Put the stuff out there that we're finding,
13:23
even if it doesn't work. So GeoGig didn't work like we wanted to. Maybe this can help some of the developers to streamline their efforts and getting more folks like us to be able to use it. And so I do have to mention that.
13:42
What kind of held us back, I feel like, was the integration into GeoServer. The documentation on that was not as much as we needed. So and then a thing that I've seen stressed on a lot
14:03
this week is the need for additional collaboration locally and on the web. So getting involved with folks in our community that are not
14:21
just GIS people, but in different industries that have an interest in spatial and kind of really maximizing everybody's efforts and interests into something that's going to work for everybody. So yeah, that's what I've got.
14:43
So if there's any questions, I'd be glad to take them. Hello. I was talking to somebody regarding the use of triggers
15:01
as a way to provide version support for multiple editors. Have you looked at that at all? No, because for this case, the lack of overlap,
15:20
we didn't need that level of complexity. But look into that. One of the improvements you wanted to make was around SLDs and kind of the difficulty in working with them. Do you have any ideas or plans as to how to improve that?
15:46
Well, yeah, it's a better editor. The composer that was an open GeoSuite was nice. I believe there's a QGIS plug-in. One of the most successful ones I was able to use
16:02
was in UDIG, actually. You could export out the SLD or export out the XML and create an SLD. But yeah, a lot of stuff was case sensitive,
16:21
and it would just throw errors in GeoTools. It was just trial and error. You'd just look at the log and see what was making it break and go back and fix it. But there was a company that made, I believe it was a German company, you could make your SLDs in ARC and spit them out.
16:42
And that worked, kind of. But once you got into any sort of real deep symbology, like kind of thematic stuff, it would just kind of at the dust. So there's a lot of stuff happening with CSS,
17:04
cartography with CSS. And so I feel like that's where a lot of the effort is at. So I'm curious what will happen with SLDs and their use. Because I think they're still widely used.
17:21
Yeah, actually, I was just going to comment on that. But there is a CSS plug-in to GeoServer. I don't know if you've looked at that. But we use that. And like you say, for thematic stuff, it's way, way nicer. And it does generate the SLD behind the scenes. So we would definitely recommend looking at that.
17:41
What's that called? It's just the, whatever, CSS plug-in to GeoServer. And it's easy to install and definitely a lot nicer. And then just one other thing about using GitHub and why GeoGig, I'm not an expert on either of them.
18:00
But I kind of get the impression that the GitHub stuff is for relatively small files. I mean, maybe a few thousand records or something. We deal with much larger data sets. And I think GeoGig is maybe aiming to work with larger data sets. Yeah, and that's something that wasn't addressed fully
18:25
in either of those talks that I had seen, actually. So yeah, it will work for the smaller stuff. And I think for the larger ones, they were kind of breaking them down into kind of more regional deals. But yeah, and I think that's kind of a limitation
18:42
for GeoJSON anyway. It's slim, but it's still got a pretty decent overhead. But for simpler cases, yeah. And I think it's just like in Vladimir's talk about simplifying. If you don't need to go with, I'm hesitant to call it bloat,
19:02
but sometimes you don't need the solution that does everything. You need the one that does what you're working on. Thank you.