Next Generation of Printed Maps
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 188 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Deutschland: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/31680 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache | ||
| Produzent | ||
| Produktionsjahr | 2014 | |
| Produktionsort | Portland, Oregon, United States of America |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
| |
| Schlagwörter |
FOSS4G 2014 Portland89 / 188
7
10
14
15
16
23
24
25
28
29
33
37
39
40
43
45
46
48
50
56
64
65
69
72
74
82
89
91
98
102
107
111
114
118
128
131
132
135
138
141
143
147
149
150
157
158
161
164
165
166
173
174
175
179
185
00:00
Textur-MappingProjektive EbeneOpen SourceClientBericht <Informatik>Kartesische KoordinatenKontextbezogenes SystemMapping <Computergraphik>ProgrammbibliothekWort <Informatik>HochdruckBitExogene VariableQuaderVersionsverwaltungMereologieComputerarchitekturComputersicherheitZentrische StreckungFokalpunktTabelleWeb-SeiteOffice-PaketFormale SpracheFunktion <Mathematik>DivisionSoftwareTemplateDateiformatGeradeKonfigurationsraumZeitrichtungBenutzerbeteiligung
02:22
MultiplikationBericht <Informatik>Lebesgue-IntegralProgrammbibliothekComputerschachNumerische MathematikArithmetischer AusdruckMapping <Computergraphik>DateiformatSpezialrechnerTemplateWeb-SeiteMAPComputerarchitekturHochdruckVersionsverwaltungBitDifferenteClientUmkehrfunktionKonfigurationsraumExogene VariableZusammenhängender GraphSoftwareentwicklerFunktion <Mathematik>Textur-MappingCoprozessorQuaderMereologieRechter WinkelTabelleQuick-SortMinkowski-MetrikTermersetzungssystemEin-AusgabeBenutzerbeteiligungFlussdiagramm
05:46
TabelleDifferenteTypentheorieTemplateCASE <Informatik>Web-SeiteSoftwaretestDatenflussClientKonfigurationsraumWeg <Topologie>Kontrast <Statistik>Objekt <Kategorie>Mixed RealityElektronische PublikationARM <Computerarchitektur>QuellcodeVektorraumCAN-BusQuaderUmkehrfunktionDatenbankVersionsverwaltungDateiverwaltungMAPBenutzerbeteiligungHochdruckMapping <Computergraphik>HalbleiterspeicherTelekommunikationKonfigurationsdatenbankNeuroinformatikServerInformationsspeicherungMultiplikationsoperatorPhysikalisches SystemSkalierbarkeitExogene VariableKonfiguration <Informatik>Zentrische StreckungDeskriptive StatistikMini-DiscGraphfärbungRuhmasseTextur-MappingKartesische KoordinatenDateiformatCoprozessorBericht <Informatik>GeometrieWeb ServicesEin-AusgabeSchlussregelVorzeichen <Mathematik>Zellularer AutomatGeradeResultanteZoomDreiDemo <Programm>MereologieOffene MengeBitmap-GraphikURLDiagramm
11:48
DatenbankElektronische PublikationTemplateFisher-InformationTypentheorieKonfigurationsraumVerzeichnisdienstSchlussregelSpezialrechnerIntegralMereologieKomponententestCoprozessorBericht <Informatik>TeilbarkeitGüte der AnpassungHochdruckDateiformatDokumentenserverProjektive EbeneAttributierte GrammatikFunktion <Mathematik>DifferenteServerGanze FunktionSoftwaretestComputersicherheitPhysikalisches SystemMultiplikationsoperatorDeskriptive StatistikDienst <Informatik>Selbst organisierendes SystemBenutzerbeteiligungMathematikTropfenMapping <Computergraphik>Leistung <Physik>VersionsverwaltungVerschlingungEin-AusgabeDatei-ServerQuellcodeZentrische StreckungURLPlug inClientFehlermeldungMetrisches SystemVariableQuick-SortGraphfärbungTrennschärfe <Statistik>Offene MengeMengenlehreMittelwertKlasse <Mathematik>DefaultLastteilungProzess <Informatik>ZeitrichtungWeb-ApplikationVektorraumZusammenhängender GraphMomentenproblemZeichenketteInformationsspeicherungDichte <Stochastik>Datensatz
18:41
Kartesische KoordinatenHook <Programmierung>SoftwaretestVersionsverwaltungMultiplikationsoperatorQuelle <Physik>CoprozessorPhysikalisches SystemGüte der AnpassungBericht <Informatik>Quick-SortWeb-ApplikationProdukt <Mathematik>PunktImplementierungDifferenteMereologieKonfigurationsraumMailing-ListeProzess <Informatik>Elektronische PublikationHalbleiterspeicherSpezialrechnerAuswahlverfahrenBitrateInformationsspeicherungRechter WinkelComputersicherheitKonfiguration <Informatik>AutorisierungTouchscreenVorlesung/Konferenz
Transkript: Englisch(automatisch erzeugt)
00:00
I'll explain a bit more about that, what's in Mapfish print and what is Mapfish print, but first just a word about myself for those of you who don't know me. I've been 10 plus years part of the geospatial open source project and have been a contributor to projects like GeoTools, GeoServer, UDIG, GeoOrchestra, GeoNetwork, Mapfish
00:27
print, Secure OWS and probably some others as well that I've forgotten. I've also listed a few of the languages that I'm currently using more or less day-to-day.
00:40
I work for Camp2Camp who is a company based in Switzerland and France and we also have an office in Austria and obviously I'm part of the geospatial division. So what is Mapfish print? Well in short it's an application for generating reports with a particular focus on mapping
01:03
and geospatial data. So very fairly simple mandate and here's an example of such a report. This is a very simple report but you can see there's some branding, north arrow, scale bar and the map and then there might be another page which would be the legend and then often
01:23
there'll be tables and other data as well in the report. Mapfish print also has a client library for creating web-based clients and here's the one for v2 version 2 and it's an XJS based library.
01:45
But the API is fairly simple so you're not tied to using this client. You can roll your own quite easily as well. This is architecture of the version 2 Mapfish print and I show this to you because I want
02:00
to give you some context when I show you the architecture of v3. So the main thing I want you to notice is the big box here, Mapfish print, contains everything. It's responsible for rendering the maps, for creating, generating the output formats, configuration, templating, layout, all of this.
02:22
Compared to v3 where the architecture is dramatically different. I should mention that version 3 is a complete rewrite. We learned a lot of lessons doing version 1 and version 2 and there are certain features that were either very hard or impossible to implement.
02:44
So with an eye to a bit more flexibility we developed Mapfish print version 3. And the thing that you'll notice is that Mapfish print has a much more focused responsibility. It's the web API and it's the kind of glue or configuration component.
03:04
We use geotools for the mapping, jasper reports we use for the layout, the templating and all the different output format support. Same as in version 2 we have an XJS based client library so you can integrate into
03:23
your XJS libraries and we're working on an AngularJS library as well. Possibly the biggest benefit we get from using jasper reports is instead of having to get a developer to create your templates, anybody essentially can create a template
03:45
using this jasper studio. It's pretty nice in that you can drag and drop images directly on the page. You get to see how big the page is. You can do things like expressions so you can add different numbers together that'll
04:02
be filled in later once the report is being generated. And the styling is very powerful. Irenports? Yeah, you can use Irenports as well I believe. I haven't tested it myself but I think so because it's the same tool, same format.
04:25
In version 2, the very last release, maybe it's not even the last release yet, we added the ability to do multiple maps per page but it was really tacked on and it's not integrated. For v3, because we're using jasper reports, we didn't have to do any work.
04:42
It just was part of the system out of the box. It's partly because, and this example illustrates two things, both some benefit we get from using jasper reports but also a low level architecture of mapfishprint v3.
05:03
So in v2, if you wanted to say have many tables or many maps, the client had to be smart and be able to provide all of the data required to generate all these maps. In v3.1, jasper reports allows you to essentially declare, put all of the maps one after another
05:23
right here with this much spacing and this sort of border. And then it will intelligently create new pages, it'll, if the map is for example too big to fit on one page, it won't cut the map in half and then split it on two pages, it'll put the whole thing on the next page.
05:40
And then in mapfishprint v3, we have a concept of a processor which takes in input data and generates other data which can be fed into the reporting engine. And so in this example, the client posts a geometry and the map.
06:00
And the processor takes this and creates a whole bunch of maps which are zoomed in portions of the geometry. So here are all the pages that are generated from this. And the client doesn't have to know virtually anything other than it's posting a map and the configuration takes care of the rest of it.
06:24
But the flow, as I call it, isn't restricted just to maps, it can be any object. So for example, you might have a whole bunch of tables or you might have a heterogeneous mix of things. So you might have a map and then a table and then a legend and then two more maps and then another table, for example.
06:41
And the report will just grow as needed. And here's a little aside from my track. I just wanted to give a contrast between different styles. So we have one table here, very simple, and then another styling. And so you can kind of see not everything you can do, but you can get kind of a small
07:04
taste for the different, the flexibility we have using Jasper Reports. This is a result from Mapfish Print V2. So in Jasper Reports we have a concept of flowing kind of like in a newspaper,
07:24
a long column. So you don't have to just flow one after another, you can flow in columns. So certain types of data, like a legend, might be fairly narrow and you don't want to just take up one third of the page and then create another page and just take up one third. You want to flow. And so a contributor added this. I have no idea who, so I'm not blaming anybody.
07:42
But clearly it wasn't tested in all cases. So here is a quick demo I just made up in maybe five minutes or so. And this illustrates, and this is part of the templating, like the application. You just define, I want three columns here, and it will fill up as necessary.
08:03
And so, yeah, this is very trivial to do and it always is legible. In V2 we had no concept of charts, but thanks to Jasper Report we not only have charts, but many different types of charts that are supported. Okay.
08:22
In version two, it was very strict where data came from. So the mapping data, or rather the mapping imagery, always came from web services. And the vector data and the table data always came from the client and had to be posted. In V3, we can get it from the web or from files or from databases
08:45
or just about any source that you can imagine. And it doesn't matter what type of data it is. If it's vector data, we can get it from any of these sources. Map imagery, it doesn't matter if it's a PostGIS, a GeoTIFF file, even a URL to a GeoTIFF.
09:02
It'll download it and render it. Same with table data and chart data. We also have a concept of preconfigured reports. So suppose you want a really dumb client. And the client just says, print me report number three. In the configuration file, you can configure the map,
09:22
which layers you want to render, the bounding box, which scale, and so on. And the client doesn't have to know any of this. It just has to know print me report three, and there'll be some nice description for the user. We also designed Mapfish print V3 for scalability.
09:41
So you don't need to set up the system like this, but this is one option you have. So you can set it up so the print server, its only responsibility is accepting web requests. And then it farms the actual work to a cluster of servers. In Mapfish V2, when a report was generated,
10:02
it was always written to the disk as a file on the local server, so you always had to keep track of, okay, this user made this request, so he has to be routed to this computer. Not so in V3. There's a concept of a file store, and it could be an S3, it could be a file, whatever. It could even be a blob in memory.
10:21
And then there's a registry for communication. That could be anything as well. It could be a Cassandra cluster, for example. But lots of times you don't have these requirements, so you could also just set up a single server which has the print server and a file system. Or you don't even need the file system.
10:40
You could just configure it so it uses memory only. And that's scalable in its own way. In version 2, the styling was what I call Open Layers 2 JSON style format. And it's very, very simple. Basically, you say the line style. So line style dashed, line color red.
11:04
And there's some very basic rules that you can apply, but not very much. In V3, because we used U tools, we have support for SLDs, so you can do styling at a particular... So you can apply style if you're at this zoom level
11:20
and a different style if you're at a different zoom level. They also have raster styling, so if you get a WMS layer, you can maybe remap the colors. So turn red to blue and blue to red, for example. But SLD, as most people agree, makes your eyes kind of cross and isn't very fun to read or write.
11:41
So we have other formats that are supported as well. For backwards compatibility, we have the same format, style format, that's in version 2, Mapfish version 2. But we also have a custom JSON style, which is kind of in between SLD and the Open Layers 2 JSON format.
12:02
And some of the features it has are, you can define a string. So it's a CQL string, for those that are familiar with that, to select the features to apply this style at. You also have scale dependencies. So you can apply this style at these scales. You can define a variable.
12:20
So you can just say the basic color is red, and then you can reuse the variable throughout the document, so you only have to change it in one place. You have defaults, so you can specify all the defaults, and then in the style, you just say, all right, change the fill color. So it's more compact and much simpler than SLD to use, but it has a good portion of the functionality as well.
12:41
And it'll get richer over time. v3 is very extensible. We have plug-ins for everything. So, for example, if your organization has some service that provides maps, well, you can write a plug-in for that, drop it into the web application, and with no changes to the source code,
13:00
you can get those maps embedded in your reports. Other plug-ins are what I call components, so scale bar, north arrow, vector styles. I told you about three different types, but you could say write a custom one where it's just an ID, and it looks it up directly from a database
13:20
or some other source. Report storage, I already mentioned this. It could be on the file or S3 or some file server somewhere. Processors, that's the idea of it takes input data and output data of any sort, and that's fed directly to the reporting engine, so you can write those as well,
13:41
output formats as well, of course. In v2, PDF was really the main output format, and if you worked fairly hard, you could get PNG and other image formats to work with various amounts of reliability. Those are first-class citizens with JASPER reports,
14:00
so the output is quite good, and it takes into account DPI and various other factors that aren't taken into account in v2. v3, we pay special attention to testing, more testing, and even more testing, because when I joined the project, there was literally zero tests in the project.
14:23
In v3, we have around 90% unit test coverage and another 90% integration test coverage, so we have, like, belt and suspenders when it comes to testing. In v2, the security, and I apologize for going so fast, but the first time I did this talk,
14:41
it took 40 minutes or so, so I'm really going. The security in v2 was limited to essentially saying, okay, these are the servers that my print server is allowed to access, deny all of the requests. But in v3, we take into consideration that if a user wants to use a file URL,
15:03
we don't want them to download the entire database or something like that using the file URL. So the file accesses sandbox to the same directory and subdirectories as the configuration file. Also, you can place access rules on templates. So one template can be accessible only by a particular set of users.
15:22
And this is particularly important for v3 because it can access the data directly out of a database, and there could be sensitive information in the report. We also add various types of metrics exposed in various different ways. So, for example, how long does a request take
15:40
to run on average? How many errors are there? How big is the average report size? How long does it take to compile the different templates and so on? Examples are a first-class citizen in Mapfish Print. And what I mean by that is
16:00
all of the examples are ran at build time. So we take the output from the build, we have an expected input, and we compare them to make sure the examples not only run, but also give the correct output. And every time we add a feature, more or less, we add an example as well. So we have a nice selection of working examples
16:21
for people to work with. The documentation in v3 is actually generated from the source code, or at least the pertinent parts of the documentation, so that it's less likely to be out of date from the source code, which is always a problem with all sorts of projects.
16:42
This does come at a cost, of course, and that cost is backwards compatibility. The configuration files are almost completely different than in v3. And while that sounds like a complete disaster, you do have to remember that a lot of the configuration is the templating. And because we have a powerful templating tool
17:01
that alleviates a lot of the pain of migrating the configuration files. For the Web API, we do have a new API, but we also have a shim for backwards compatibility. So most clients should be able to work using that compatibility API while they're working on migrating to the new API.
17:23
Okay, so Mapfish print v3. Bigger, better, faster, smarter, stronger. The documentation is at this URL here. This is a final URL, but I do have to warn you that the documentation is far from finished,
17:41
and the styling will most likely be cleaned up. I want to add more links to kind of cross-reference between different attributes and processors and so on. The different parts. But it gives you a place to kind of start playing. And along with the examples, you can get quite a ways with that. At the moment, the repository,
18:02
it's in a separate repository, but that's only a temporary thing. We're gonna be merging it back into the normal Mapfish repository before too long. Good. And that's everything. So I'll take questions now. It sounds like that Jasper Reports
18:22
is gonna replace the config YAML. Is that correct? There is still a config file, a YAML file, but it's more a functional description of what the system does, not the layouts and the templating. So it's typically fairly small.
18:43
When do you think we will have our first official release of v3? Well, as always, that's hard to say. But we are putting a system in production. We've almost got it ready as of two weeks ago, and so it should be in production in a couple of weeks.
19:00
And so I'd like to see how that goes and iterate a couple times on that and maybe in a few months, beginning of next year perhaps. How hard would it be to hook in, you know, the customer's BI system? Well, the system is pluggable, so you can do that.
19:21
It's designed to be able to do that. But a few of the processors, for example, assume Jasper Reports. And so you wouldn't be able to use those processors in your configuration file. That's all. But you can completely replace it with, say, BERT or some other custom implementation.
19:41
Can you get your reference, the images, out of the export? At the moment, no, you can't. Because it's an entire report, so only part of it is actually really spatial, right? But, yeah. Because it's a plug-in, you could add that, but I haven't seen very many requests for that, so it's not high on my list.
20:09
Is the security system pluggable for authorization? Yes, it is. It uses spring security, so you have all sorts of different options, from CAS to LDAP to in-memory user store.
20:24
So, yes, very pluggable. Hi. As you know, we integrate MapPrint in GeoServer. I was wondering how difficult or easy it is to take it as a library and use it in another application,
20:43
another web application. For GeoServer in particular, it should be pretty easy, because I kind of made a point of not using any spring APIs that are, like, new. So you can use it probably with the GeoServer one, just to exclude all of those dependencies.
21:00
GeoTools, I can't remember what version, but it should be compatible as well with the GeoServer versions. Otherwise, yeah, you can download it as a jar, as well as a command line application for testing and stuff like that.
21:20
Any other questions? No? Okay, good. Thank you very much.