OpenSource GIS applied

Wednesday, June 19, 2013

ArcGIS server and additional WMS styles

Today I had the opportunity to do some experimenting with publishing WMS services on an ArcGIS server instance. My goal was to publish some alternative styles for a WMS layer (most wms clients offer possibility to change a style on a layer, if multiple styles are published in capabilities). Unfortunately it appeared to be quite a challenge to get this done...

As mentioned here, http://resources.arcgis.com/en/help/main/10.1/index.html#/Using_Styled_Layer_Descriptors_with_WMS_services/015400000468000000/, Esri wants me to create an SLD file by hand (based on their snippets) and attach that to the service definition. Ok, quite experimental, but let's try

I used GeoCat bridge (http://geocat.net/bridge) to create the SLD from ArcMap. When I pointed to the SLD file created by bridge (on my local drive), no warning whatsoever, but no additional styles appeared in the WMS. It appears the file should either be located in the ArcGIS Server machine or accessible via the web (was it really strange for me to expect the file would be uploaded during publication?). So after having uploaded the SLD to a web account and inserting the url, the alternative style appeared, yeah!

The styles created by bridge need minor changes to get them working as extra styles in ArcGIS Server. For example the naming of layers is quite bizar in AGS. Layernames are actually increasing numbers (it must be quite a challenge to keep those numbers synchronised over time). So the named-layer section in the SLD should have something like

<sld:NamedLayer><sld:Name>1</sld:Name></sld:NamedLayer>

Also all styles for all layers in the service should be in a single SLD file, so the separate bridge SLD files should be concatenated to a single file.

Note that ArcGIS does not support the full set of SLD tags available in for example geoserver.
Test your style first before publishing to ArcGIS Server by adding the sld parameter to a single wms request.

http://AGS/Service/MapServer/WmsServer?LAYERS=0&SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&STYLES=Velocity&FORMAT=image%2Fpng&SRS=EPSG%3A28992&BBOX=177900,314900,178000,315000&WIDTH=256&HEIGHT=256&sld=http://www/test.xml

During my small research I noticed following SLD tags/conventions not supported by AGS:
- <sld:rotation> on sld:mark is skipped
- having a ttf symbol as a wellknownname (convention within geoserver community), in stead use the well known names: circle, square, triangle, star, cross or x

Sunday, June 02, 2013

Amazing list of geonetworks around the globe

Wednesday, April 03, 2013

Auto ordering point layers on top of line/polygon layers in GeoExplorer

Once in a while we get this question for GeoExplorer (GXP):

Force the webviewer to draw points over lines over polygons regardless of the layer menu structure
Off course i get the idea, one will not hide the point layer by overlaying it with polygon features. But still implementing this feature is far les obvious as expected.

This feature is not common in Geo, one will not find it in common libraries. Impact will be quite high to change it code-wise in GXP. One would need a) a procedure to determine the featuretype of a layer (point/line/polygon/mixed/grid) and b) a procedure to reorder the layers triggered by a layer-add/move event, without altering the tree-structure. I'm not even sure a. is obvious, since featuretype is not advertised by default in WMS capabilities.

This might be one of those points where you'll have to decide if the GXP library is suitable for you, it presumes some default GIS workflow, and it's quite impactfull to change it. In such a case using the plain components OpenLayers/Geoext might solve your challenge more easily. But leaving you with a viewer with far less functionality by default.

If a question like this pops up, check the use case! Maybe there are alternatives to get similar behaviour, which do fit the common GIS workflow. For example similar behaviour could be managed by configuration, where one should configure all point layers on top.

By the way, in most usecases I'm not in favour of having tens of layers in a TOC. In most usecases I prefer to have just a couple of layers in a map and present the user another map with an alternative set of layers if they are working in another context (WMC/OWSContext). But give them the possibility of adding additional layers to the context via a CSW-interface.

Saturday, December 08, 2012

Vooruitblik op GEO in 2013

De afgelopen jaren is het op een aantal terreinen hard gegaan met de ontwikkelingen in het ruimtelijke software veld. Google maps, OpenLayers hebben projecten als Mapbuilder en Chameleon (op zich hele leuke projecten) verdreven. En binnenkort zullen de html-5 viewers het stokje overnemen (leafletjs). Niemand durft meer een kaartje in Flash op te zetten en iedere website moet opeens weer leesbaar zijn op een 300*500 schermpje (of voldoen aan de webrichtlijnen). QGis heeft heel wat gebruikers overgenomen van de gevestigde partijen als ze niet al naar een WebClient overgestapt waren. Als u in 2005 echter zoals velen gekozen heeft voor OGC services als basis voor uw geo infrastructuur, dan is dat een duurzame keuze gebleken en de verwachting is dat dat ook nog wel zal blijven. Nog zo'n trouwe metgezel is mapserver, nog steeds de meest betrouwbare opensource kaartmotor die ik ken. Hieronder wat overpeinzingen over de afgelopen periode, ter inspiratie voor 2013...

Belangrijke recente ontwikkelingen zijn de ontwikkelingen rond de diverse portalen (PDOK, PGR, WGR) die in een grote mate voorzien in allerlei datasets met webservices ontsloten vanuit de bron (Kadastraal, BRT, BAG, Luchtfoto's, CBS, NWB). Hierdoor zal men steeds minder zelf tot aanschaf en opslag van door derden verzamelde gegevens over hoeven te gaan. Al bevatten de momenteel beschikbare services in veel gevallen nog niet een volledige historie. Voor ArcGIS en QGis zijn extensies beschikbaar die het gebruik van bijvoorbeeld de PDOK services vergemakkelijken.

De portalen en daarmee gepaard gaande regelgeving (Inspire, Basisregistraties) stellen wel vrij hoge eisen aan de dataleveranciers Dit speelt op diverse niveaus: ondersteuning van een datamodel, volledigheid van de metadata, voldoen aan de standaarden tot beschikbaarheidseisen van de webservices.

Als Geocat ondersteunen we overheden en bedrijven bij het publiceren van geografische datasets (op intra, extra en internet). Ons belangrijkste product is de opensource catalogus Geonetwork, de lijm in iedere spatial data infrastructure (SDI). Het terrein van metadata in combinatie met hoge eisen die Inspire/geonovum aan de metadata stelt maakt dit aspect voor velen vrij lastig. Geonetwork is geen eenvoudig product, echter door optimale inrichting van de templates, geautomatiseerde ETL processen en een losse catalog ontsluiting is het gebruik van de catalog binnen een organisatie wel degelijk te optimaliseren, zodat bijvoorbeeld ook niet-geo-gebruikers er goed mee aan de slag kunnen. Een portaal met een eenvoudigere interface (maar waarmee Inspire compatibiliteit weer lastiger te realiseren is) is bijvoorbeeld Geonode met daarin pyCSW.

Als voorbeeld, via de CSW extensie kan vanuit ArcGIS (maar ook arcgis explorer en QGis kennen een CSW extensie) direct gezocht worden in een catalog. De gevonden resultaten zijn direct aan de kaart toe te voegen. Ook Openlayers kent CSW-zoekopties.

Omdat het publiceren van metadata door velen als lastig ervaren wordt hebben we als geocat het initiatief genomen een "bridge" product te ontwikkelen dat publicatie van ArcGiS projecten naar een Open SDI tot het drukken op een knop reduceert. De data, styling, metadata en/of context wordt gepubliceeerd als kaartlagen in Geoserver of Mapserver, de metadata in geonetwork, waarbij zorg gedragen wordt dat alle wederzijdse koppelingen tussen service, dataset en metadata geautomatiseerd gelegd worden. Een context bestand is de OGC:variant van een themakaart. Een set lagen, een inzoom-extent en een titel met een omschrijving erbij. Optimaal inzetbaar als interactief kaartje bij een webpagina, email of bij netcentrisch werken, waarbij een specialist een kaart voorbereid en deze onder een community verspreid om een ruimtelijk probleem te duiden.

En wat komt er verder nog op ons af... Sensor services, 3D, Big data/Open data, authorisatie, WPS...

Steeds meer bedrijven en overheden hebben sensoren hangen/drijven, waarvan men de data stroom in sommige gevallen wil/moet delen met politie, waterschap, gemeente enz. Dan komt de OGC standaard SWE (sensor web enablement) om de hoek kijken. Deze ontwikkelingen zijn relatief nieuw, maar het is al vrij zeker dat bijvoorbeeld Inspire SWE op zal nemen in haar requirements voor bepaalde dataset-publicatie vormen. In geonetwork is SWE in de basis aanwezig, maar ik verwacht daar de komende tijd veel ontwikkeling rond. De meest gebruikte open source sensor server software is momenteel 52 north.
3D is nog altijd lastig om te visualiseren. Er zijn nauwelijks open source GIS pakketten die een goede 3D weergave hebben. De kaartserver deegree heeft een vrij groot pallet aan opslag mogelijkheden voor 3D data en ondersteuning voor de web perspective view service en 3D CityGML (via WFS). Maar er zijn nog nauwelijks clients die daar gebruik van kunnen maken.
2012 staat onder andere in het teken van open data, door de overheid gestimuleerd is het vliegwiel gaan draaien, wekelijks wordt weer een nieuwe dataset gepubliceerd als open data (PDOK, RDW, RCE, Waterschappen). Altijd goed om de data licenties goed op een rijtje te hebben, sommigen dienen altijd vergezeld te gaan van auteurs vermeldingen (attribution), anderen mogen niet commercieel uitgebaat worden. De andere veelgehoorde term was big data. Met name de vele sensoren die we hebben genereren sneller data dan we kunnen verwerken. Een goede strategie in opslag en verwerking is dus onmisbaar.
In tegenstelling tot het punt hierboven wordt ook het aspect van authenticatie voor ruimtelijke services steeds belangrijker. Steeds meer processen lopen via het internet, de data komt overal vandaan. Men wil voorkomen dat niet geautoriseerde mensen bij de gevoelige data kunnen, maar tegelijkertijd ook niet steeds opnieuw een (afwijkend) wachtwoord in toetsen (single sign-on). En hoe dwing je een fair-use policy af?
WPS (Web Processing Services) gaan verder waar WMS en WFS ophouden. Analyses, route berekeningen, processen starten/volgen, alles is mogelijk met deze standaard die eigenlijk alleen een standaard biedt voor het formaat van de in- en output parameters. Met een product als taverna zijn dit soort services te combineren tot een workflow, alleen wordt alles remote uitgevoerd.

Een keuze voor Open Source?
In de praktijk blijkt dat de Open Source producten goed aan de OGC standaarden voldoen en qua functionaliteit niet onder doen voor de gesloten alternatieven. Ze passen dus goed in een architectuur gebaseerd op Open standaarden. Een eventueel nadeel is de bundeling van een aantal verschillende producten tot een SDI. Ik zie dat echter als een voordeel, met een Suite van een leverancier heeft men niet de mogelijkheid er een slecht presterende component uit te halen en te vervangen voor een beter alternatief. Een ander groot voordeel is dat als er wat mis is, men relatief eenvoudig op zoek kan naar de oorzaak. Rond Open Source producten zijn grote communities actief die actief op gebruikersvragen reageren. Er zijn ondertussen voldoende bedrijven die professionele dienstverlening hebben rond open source software, zoals OpenGeoGroep, B3Partners, Aris, GeoCat. Zij ondersteunen bij installatie, configuratie, aanpassingen, nieuwbouw, onderhoud en storingen.

Ik hoop u hierbij wat aanknopingspunten gegeven om uw visie rond geo verder uit te diepen.

Ik was dit verhaal aan het typen aan een potentiële klant, op basis van een advies aanvraag en dacht waarom niet op de blog. Anderen vinden het misschien ook interessant, zo'n compact overzicht.

Wednesday, November 07, 2012

Apply combined fill on multiple fields in geoserver SLD

Imagine you want to add a style to a map layer where the style is applied based on values of two attribute fields. Implementation like below seems quite logical if you see it, but I was quite surprised it works out of the box in geoserver... (Alternative would be to add the layer twice or have 10*10 rules, each field 1 value times each field 2 value)

The use case is a polygon fill based on crop cultivar as background-fill color and association (other crop that is mixed in) represented as a hash-pattern on top of the fill.

In geoserver you can add two featurestyles to a layer user style, the first implementing the background fill based on field A and a second style based on field B

<StyledLayerDescriptor>
<NamedLayer>
<UserStyle>
<Name>test_style</Name>
<FeatureTypeStyle> ...</FeatureTypeStyle>
<FeatureTypeStyle>... </FeatureTypeStyle>
</UserStyle>
</NamedLayer>
<StyledLayerDescriptor>

In featuretypestyle 1 now define the backgroundfill based on field 1

...
<Rule>
<Name>Cavendish</Name>
<ogc:Filter>
<ogc:PropertyIsEqualTo>
<ogc:PropertyName>cultivar_type</ogc:PropertyName>
<ogc:Literal><![CDATA[1]]></ogc:Literal>
</ogc:PropertyIsEqualTo>
</ogc:Filter>
<PolygonSymbolizer>
<Fill><CssParameter name="fill">#FF0000</CssParameter></Fill>
</PolygonSymbolizer>
</Rule>
....

And in featuretypestyle 2 define the hash-pattern based on field 2

...
<Rule>
<Name>Associated with established perennial crops</Name>
<ogc:Filter>
<ogc:PropertyIsEqualTo>
<ogc:PropertyName>association</ogc:PropertyName>
<ogc:Literal><![CDATA[1]]></ogc:Literal>
</ogc:PropertyIsEqualTo>
</ogc:Filter>
<PolygonSymbolizer>
<PolygonSymbolizer>
<Fill>
<GraphicFill>
<Graphic>
<Mark>
<WellKnownName>shape://vertline</WellKnownName>
<Stroke><CssParameter name="stroke">#000000</CssParameter></Stroke>
</Mark>
</Graphic>
</GraphicFill>
</Fill>
<Stroke><CssParameter name="stroke">#6E6E6E</CssParameter><CssParameter name="stroke-width">1</CssParameter>
</Stroke>
</PolygonSymbolizer>
</Rule>
...

This will result in a combined style as follows

A potential challenge here is the legend-display, but the two featurestyles are nicely placed after each other...