Welcome to Planet OSGeo

April 15, 2014

Boundless Blog

Thoughts from State of the Map US 2014

Gretchen PetersonThe State of the Map US 2014 conference, a two-day conference covering all things OpenStreetMap, was held this past weekend in Washington DC. It was nice to attend as part of the Boundless contingent and meet — in person — tons of people whom I had only heretofore known via the internets.

Aside from the inspiration provided by the gorgeous weather and the cherry blossoms, there was also inspiration in abundance at the conference for cartographers. Every cartographer should become familiar with OpenStreetMap data if they aren’t already. It’s a bit of a bear to work with because it is in a different structure than we are normally used to (nodes and ways mean anything to you?) but you’ll see the benefits if you download a state-wide or city-wide extract from one of several sites (such as geofabrik or Metro Extracts) and start using it in your map-making medium of choice. The dataset provides a comprehensive collection of roads, buildings and building types, points of interest, and so on. And it’s free!

There were many talks I didn’t get to see because there were two concurrent tracks, but the ones that I attended focused heavily on tools that for using OpenStreetMap data, including GeoGit, TileMill, Esri, QGIS, and PostGIS. However, there were still some cartographic takeaways.

  • Kate Watkins, Seth Fitzsimmons and Alan McConchie told us that a great way to build a stylistically cohesive basemap is to focus on three main hues, along with variations on those hues.

  • In that same talk we saw some great examples of labels that break all the rules: the leading and kerning (that’s line spacing and character spacing, basically) are decreased to negative values and the halos are very large and black. Of course this is the opposite of what most texts will recommend but it just proves that breaking the rules once in a while can make for some neat cartographic effects.

  • Eric Theise showed us that applying some of the devices of experimental film to maps, such as perception distortion, can be a creative way to get people thinking. Eric and I were discussing this later on in the day when he mentioned that he thought it would be interesting to have a map that taunted you if you tried to click on a feature to find out more about it. Something like, “You’d like to know what this building is, wouldn’t you?!”

  • Kevin Bullock told a great story about a map of India that was produced in the 1800s with crude tools, took 70 years to complete, and astonishingly accurate despite these and other limitations. And you thought your map products took a long time to produce!

  • Our own Jeff Johnson rounded out the weekend with a more technical talk that examined the ways in which GeoGit could lead to a more distributed and decentralized architecture for OSM.

There was a lot more material covered, of course, and these points focused just on the cartography aspect of OpenStreetMap use. All the talks are now posted on the schedule part of the conference website so definitely take the time to watch them!

If you’re still curious about State of the Map, I recommend this great recap from Peter Batty which provides more details about the event and reviews other issues in the OpenStreetMap community including vector tiles, licensing, passive crowdsourcing, geocoding and more.

The post Thoughts from State of the Map US 2014 appeared first on Boundless.

by Gretchen Peterson at April 15, 2014 08:43 PM

FOSS4G 2014

Regular Session and Academic Track proposals due today!

The time for procrastination dwindles…

Regular Sessions and Academic Tracks are both due today.

 

Time1

Bonus points to anyone who knows where in PDX this clock is located.

 

 

by Eli Adam at April 15, 2014 06:01 PM

GeoTools Team

GeoTools 10.6 Released



The GeoTools community is pleased to bring you GeoTools 10.6:
Artifacts are also available from our Maven repository.

This is our first GeoTools maintenance release offering an extra six months of the GeoTools 10 series. This six month windows provides a grace period allowing you schedule your upgrade to GeoTools 11 while still receiving bug fixes. For more information see Changing Tracks on the the GeoTools Release Train.
The GeoTools 10.6 Release Notes include details on changes since 10.5. These include:
  • app-schema improvements handling nulls and undefined namespaces
  • SpatialLite supports now supports views in addition to tables
  • Oracle support continues to approve with better CRS axis name and spatial index support
  • Small fixes for GeoJSON, GeoTIFF, process annotations

About the GeoTools 10.x Series

Summary of the features for the GeoTools 10.x series:
  • Structured grid coverage readers allow raster data sources that publish composite data products to expose individual rasters (ie granules) for processing, while still providing a seamless experience for rendering. The mosaic and NetCDF modules are the first ones to implement these new interfaces.
  • Efficient support for multiple coverages in GridCoverageReader provides ad-hoc access to raster formats that publish more that one data product. A image mosaic made of NetCDF granules and single file NetCDF sources are the first implementors of these new capabilities
  • new implementation of Shapefile DataStore (based on ContentDataStore superclass). This upgrade should be seamless for all users using DataStoreFactoryFinder. If you explicitly made use of the ShapefileDataStore or IndexedShapefileDataStore class please check the upgrade instructions.
  • The transform module graduated to supported status, providing a seamless way to rename, retype and hide SimpleFeatureSource attributes, as well as creating new ones based on OGC Expression
  • Additional OGC modules for the WCS 2.0 and WCS 2.0 EO models as well as adding XML parsers and encoders
  • Support for fills made with randomized symbols
The 10.x series features a number of research and development activities:
  • NetCDF has been updated to take advantage of the new coverage API introduced above
  • GeoPackage: a sample implementation of the geopackage spec that is currently being developed by the OGC
If you are interested in helping out please introduce yourself on geotools-devel mailing list.

Enjoy,
The GeoTools Community

by Ben Caradoc-Davies (noreply@blogger.com) at April 15, 2014 11:51 AM

Peter Batty

Report on another great State of the Map conference

Summary I spent the past weekend in Washington DC for State of the Map (SotM) US, the OpenStreetMap conference. It ended up selling out, with around 500 attendees, making it the largest OpenStreetMap event yet. As with previous SotM events I’ve attended (the last one being in Denver in 2011), I found it very enjoyable and interesting, and there was great energy about it as always, much more than

by Peter Batty (noreply@blogger.com) at April 15, 2014 05:02 AM

April 14, 2014

Boundless Blog

Harvesting Metadata from OpenGeo Suite using CSW

Justin DeoliveiraThe release of OpenGeo Suite 4.0 added Catalogue Services for the Web (CSW) support to the impressive list of OGC services supported by the product. CSW is an open standard defined by the Open Geospatial Consortium (OGC) that makes it easier to search for and discover geospatial data in a machine-readable way. With CSW support, metadata about data and web services is more discoverable, making it easier to manage and advertise data as holdings grow. We explained how to install the CSW plugin and described the mechanics of how a CSW service works in a previous post, but this post will describe how to harvest metadata from GeoServer.

Because CSW can be automatically harvested, its easier to integrate new services into existing spatial data infrastructures. GeoServer offers a minimal implementation of the CSW specification that is limited when compared to implementations in more full-fledged catalogs. This is by design, as it is meant to be as lightweight as possible while still providing the capability to offer metadata about the contents of a GeoServer instance. This metadata can easily be consumed by a more complete CSW implementation that supports harvesting. While specific to GeoNetwork, the same workflow is possible with other servers such as pycsw or Esri GeoPortal Server.

Getting Started

The first step is to install OpenGeo Suite with the CSW plugin. For this post we used OpenGeo Suite 4.0.2 and the installation instructions from our previous post. Once the source catalog is installed, the next step is to download and install a catalog into which to harvest metadata. For this post we used GeoNetwork 2.10.2 and followed the detailed instructions in the documentation.

We installed both OpenGeo Suite and GeoNetwork on the same local machine so all links reference http://localhost. One important note is that since OpenGeo Suite and GeoNetwork use the same default port (8080), one must be changed if you intend to run them on the same machine. For this post we set OpenGeo Suite to run on port 9080 by following the documentation.

Configuring Harvesting

Once OpenGeo Suite is up and running, visit the GeoServer administration page at http://localhost:9080/geoserver. If the CSW plugin has been installed correctly, you’ll see a link to the capabilities document on the right hand side of the page. Copy this link as you’ll need it shortly.

Ensure that GeoNetwork is started and visit http://localhost:8080/geonetwork. Login with the “admin” account — by default the password for this account is “admin”. Once logged in, visit the “Administration” page and go to the “Harvesting Management” link about halfway down the page.

The harvesting page allows us to add a link to another CSW from which to harvest metadata. The goal here is to harvest from GeoServer. Start by clicking the “Add” button, then expand the “Type” drop down and select “Catalogue Services for the Web ISO Profile 2.0”.

This results in a form requesting information about the server from which to harvest. For this step we must fill out the following:

  • Set “Name” to “GeoServer CSW” and “Service URL” to the capabilities url we copied previously.

  • Uncheck “Use account” since in this case our CSW is not secured by a username and password.

  • Choose “Datasets” under the “CATEGORIES” list.

Once the service has been added, return to the harvesting page and select the “GeoServer CSW” service, then click the “Run” button. After a few seconds click the “Refresh” button. Upon success you should see the “Last run” timestamp updated.

Search & Discover

Once the harvest job has completed, GeoNetwork should have all the metadata provided by GeoServer. In this example, GeoServer is publishing a number of layers featuring Natural Earth data. Let’s examine one such layer: parks and protected areas.

Metadata from GeoServer such as title, abstract, and keywords have all been defined. Once GeoNetwork has harvested all this metadata it becomes possible to search using the form on the GeoNetwork home page. As expected, entering the search term “parks” returns on the appropriate layer.

Since the metadata returned by GeoServer provides information about other services, such as WMS, we can browse the data directly in GeoNetwork as well.

The post Harvesting Metadata from OpenGeo Suite using CSW appeared first on Boundless.

by Justin Deolivera at April 14, 2014 03:49 PM

Jackie Ng

Announcing: mapguide-rest 0.7

Before we continue our blogging journey into the rest of mapguide-rest's data publishing framework, here's the second release of mapguide-rest.

Here's what this new release offers

ACLs for published data sources

We now let you have some level of control as to what users and groups can access a given published data sources, which is important if you are exposing representations that support POST/PUT/DELETE operations and even more important if this is on a public-facing site. You don't want Joe Anonymous MapGuide user to be able to POST/PUT/DELETE to your data sources willy nilly unless you have configured such data sources to allow for such things to happen.

Consider this example from a recent post

{
    "Source": {
        "Type": "MapGuide",
        "FeatureSource": "Library://Samples/Sheboygan/Data/Parcels.FeatureSource",
        "FeatureClass": "SHP_Schema:Parcels"
    },
    "Representations": {
        "xml": {
            "Adapter": "FeatureSetXml",
            "Methods": {
                "GET": {
                    "MaxCount": 500
                },
                "POST": {},
                "PUT": {},
                "DELETE": {}
            }
        }
    }
}

This configuration will now deny all users because no ACLs have been defined for it. A configuration like this

{
    "Source": {
        "Type": "MapGuide",
        "FeatureSource": "Library://Samples/Sheboygan/Data/Parcels.FeatureSource",
        "FeatureClass": "SHP_Schema:Parcels"
    },
    "Representations": {
        "xml": {
            "Adapter": "FeatureSetXml",
            "Methods": {
                "GET": {
                    "MaxCount": 500,
                    "AllowGroups": ["Everyone"]
                },
                "POST": {
                    "AllowUsers": ["Administrator", "Author"]
                },
                "PUT": {
                    "AllowUsers": ["Administrator", "Author"]
                },
                "DELETE": {
                    "AllowUsers": ["Administrator", "Author"]
                }
            }
        }
    }
}

This will define the following access rules:
  • GET: Anybody can access the data source
  • POST: Only the Administrator and Author users (and related session IDs) can access the data source. Everyone else will be denied access.
  • PUT: Only the Administrator and Author users (and related session IDs) can access the data source. Everyone else will be denied access.
  • DELETE: Only the Administrator and Author users (and related session IDs) can access the data source. Everyone else will be denied access.
Auto-API documentation for published data sources

Thanks to the integration of Swagger UI for our REST API documentation needs, and the fact that all published data sources will offer a "fixed" REST API to interact with it, we now can provide automatic REST API documentation for any published data source.

Simply append a doc/index.html to access a data source's API documentation



New REST API routes

This release includes plenty of new routes to play with
  • GET /library/{resourcePath}.WebLayout/viewer (Load the given Web Layout into the AJAX viewer)
  • GET /library/{resourcePath}.ApplicationDefinition/viewer/{template} (Load the given Flexible Layout in Fusion with the given template)
  • POST /library (Load a package file into the repository)
  • GET /services/getschemamapping.{type} (Get the schema mapping for a given FDO provider and partial connection string)
  • GET /library/{resourcePath}.FeatureSource/preview (Launch a schema report preview on the given Feature Source)
  • GET /library/{resourcePath}.LayerDefinition/preview (Launch a AJAX viewer preview of the given Layer Definition)
  • GET /library/{resourcePath}.MapDefinition/preview (Launch a AJAX viewer preview of the given Map Definition)
  • GET /library/{resourcePath}.SymbolDefinition/preview (Render a preview of the given Symbol Definition)
  • GET /library/{resourcePath}.WatermarkDefinition/preview (Launch a AJAX viewer preview of the given Watermark Definition)
  • GET /session/{sessionId}/{resourceName}.WebLayout/viewer (Load the given Web Layout into the AJAX viewer)
  • GET /session/{sessionId}/{resourceName}.ApplicationDefinition/viewer/{template} (Load the given Flexible Layout in Fusion with the given template)
  • GET /session/{sessionId}/{resourceName}.FeatureSource/preview (Launch a schema report preview on the given Feature Source)
  • GET /session/{sessionId}/{resourceName}.LayerDefinition/preview (Launch a AJAX viewer preview of the given Layer Definition)
  • GET /session/{sessionId}/{resourceName}.MapDefinition/preview (Launch a AJAX viewer preview of the given Map Definition)
  • GET /session/{sessionId}/{resourceName}.SymbolDefinition/preview (Render a preview of the given Symbol Definition)
  • GET /session/{sessionId}/{resourceName}.WatermarkDefinition/preview (Launch a AJAX viewer preview of the given Watermark Definition)
You can use the provided interactive REST API documentation to find out more information about these new routes

Improved HTML representation of the site repository

The default HTML representation of the site repository is very bare-bones and primitive.

With the power of Bootstrap 3, we've brought the HTML representation into the 21st century :)


Most of the resource options now show their results inline




Any Web Layout or Application Definition resources now expose new options for you to launch them in their respective AJAX or Fusion viewer



This is still experimental code, so standard disclaimer: use in production at your own risk.

Download

by Jackie Ng (noreply@blogger.com) at April 14, 2014 02:14 PM

April 13, 2014

Slashgeo (FOSS Articles)

Batch Geonews: Get Your Google Glass on April 15, TopoJSON, GDAL/OGR for ArcGIS, Ukraine Maps, and much more

Here's the recent geonews in batch mode.

On the open source / open data front:

On the Esri front:

On the Google front:

Discussed over Slashdot:

In the everything else category:

In the maps category:

by Satri at April 13, 2014 07:05 PM

Jo Cook

Complexity vs Quality

Recently I had need to evaluate a Proprietary Desktop GIS (PDG for short) to document the procedure for doing a Thing for a client. To avoid any mud-slinging and name calling , I’m naming neither the PDG or the Thing, I’ll just say that the Thing is something that the PDG claims to be able to do. This is not a blog post excoriating PDGs by the way, it’s a reflection on the virtues of simplicity, good documentation, and being honest and open.

So, I download a trial version of the PDG and spend 2 hours installing and licensing it. During this time I have to consult the documentation on exactly what licensing options I wanted for a TRIAL piece of software. I also have to consult the documentation on exactly how to apply the license. No mind, I get the software installed and working and try and do the Thing. I remember from several years ago, last time I tried to do the Thing with the PDG, that it was slightly tricky, but several versions have been and gone, all of which claim to be able to do the Thing. Consequently though, I cut the PDG a bit of slack when it can’t do the Thing, and I try the work-around. Yes, that still works, though I don’t know how you’d guess that from the error messages or the documentation. It’s not ideal to need two methods of doing the Thing but hey ho. I also cut the PDG some slack when it tells me that I can only do the Thing if I adhere to some very unusual naming conventions, which will mean that, should I need to do this for real, I will have a lot of work to do renaming a bunch of stuff.

Let’s take this up a level. I don’t only need to do the Thing, but also the related Slightly More Complicated Thing (SMCT for short) too. I confess that the documentation doesn’t really say out and out that the PDG can do this, but it certainly implies it. Only, it doesn’t seem to be able to without a license for it’s rather more expensive elder brother, the Proprietary Server GIS (PSG for short). However, to explain this to the client, I will need some documentary proof. I can find blog and forum posts admitting it’s true, and for all I know there might be lots of information in the knowledge base for the PDG and PSG but you have to have a customer number to access this and because I am only evaluating the software, I haven’t purchased it yet, so I don’t have one of those.

So, I ask some questions of colleagues, and while waiting for them to get back to me, I try some work-arounds for the SMCT. Needless to say, they don’t work either.

A colleague finally gets back to me. After some incredulity that the PDG really can’t do the SMCT when everything implies that it can, said colleague, in his other role as a re-seller for the PDG rings them up and asks. “Yes, we can do that” says the first person, let me find a Thing-specialist to explain how. “No, we can’t do that” says the Thing-specialist. “Our reasons are very complicated, but here’s some obscure documentation that actually admits that we can’t do it”. We let the client know the good news.

As I said earlier, this is not a post excoriating PDG, it’s a reflection on the virtues of simplicity, good documentation, and being honest and open.

Reflection One: The whole process of installing the PDG and discovering the various methods of doing the Thing was needlessly over-complicated. This may be due to the long history of the PDG, and the enormous feature-set, but it feels like bloat. Complexity and a huge feature-set do not necessarily equate to quality, and similarly simplicity and a smaller feature-set are not a bad thing.

Reflection Two: Why hide documentation behind what’s effectively a pay-wall? Had I actually been in the market for purchasing this software, I would have given up at that point. Documentation should be freely available to everyone.

Reflection Three: We really should not have needed to get a re-seller to ring up, and speak to two different people, just to get a definitive answer on the capabilities of a piece of software. This is wrong on so many levels.

In my opinion, these points have nothing to do with the license applied to the source code of the software, or the name on the box: Don’t fall prey to Zawinski’s Law, do make your documentation comprehensive and easily accessible, and do be honest about your capabilities. I’d pay good money for that.

April 13, 2014 02:28 PM

April 12, 2014

Markus Neteler

Workshop at FOSS4G 2014: Spatio-temporal data handling and visualization in GRASS GIS 7

Drowning in too many maps? Have some fun exploring fascinating geometries of changing landscapes in Space Time Cube and creating 2D and 3D animations from time series of geospatial data. Learn about the new capabilities for spatio-temporal data handling in GRASS GIS 7 (http://grass.osgeo.org/grass7/) and explore various techniques for dynamic visualizations.

First, we will introduce you to GRASS GIS 7, including its spatio-temporal capabilities and you will learn how to manage and analyze geospatial data time series. Then, we will explore new tools for visualization of spatio-temporal data. You will create both 2D and 3D dynamic visualizations directly in GRASS GIS 7. Additionally, we will explain the Space Time Cube concept using various applications based on raster and vector data time series. You will learn to manage and visualize data in space time cubes (voxel models). No prior knowledge of GRASS GIS is necessary, we will cover the basics needed for the workshop. All relevant material including an overview of the tools and hands-on practical instructions along with the sample data sets will be available on-line. And, by the way, GRASS GIS is a free and open source geographic information system (GIS) used for geospatial data management, analysis, modeling, image processing, and visualization which runs on Linux, MS Windows, Mac OS X and other systems.

Presenters: Vaclav Petras, Anna Petrasova, Helena Mitasova, Markus Neteler

When:  FOSS4G 2014, Sept 8th-13th 2014, Portland, OR, USA

Register at: https://2014.foss4g.org/schedule/workshops/#wshop-526

by neteler at April 12, 2014 12:30 PM

Paulo van Breugel

Add multiple raster or vector map layers to current map display in GRASS GIS

If your mapset contains many raster or vector layers GRASS offers a very handy feature to quickly select the layers you want to add to your current map display. In the layer manager, click Ctrl+Shift+L to open the ‘add selected map … Continue reading

by pvanb at April 12, 2014 10:00 AM

April 11, 2014

FOSS4G 2014

Regular Session and Academic Track proposals due early next week (4/15)

April 11, 2014
Portland, OR, USA

Regular Session and Academic Track proposals due

A reminder to all FOSS4G attendees – the proposal submission deadline for both the Academic Track and Regular Sessions is next Tuesday, April 15th. For the Regular Sessions, we strongly recommend reviewing our advice for successful proposals before submitting.

The community voting on the Regular Sessions will directly follow the deadline, April 18th to 28th.

Travel Grant Announcement

We realize that traveling to and attending a conference can be expensive, and that not everyone who uses or develops open source software has provided funding to pay their way or the means to pay for it themselves. To make sure that as many deserving people as possible can attend FOSS4G, we’re creating a travel grant program with funds to cover registration and travel costs. Watch for details coming soon.

One additional reminder: Early Bird Registration is open!

Important Conference Dates

See the full calendar for more details.

  • April 15th: Academic Paper/Presentation Proposals Due
  • June 15th: Early bird registration ends
  • Sept 8th-9th: Workshops
  • Sept 10th-12th: Main Conference
  • Sept 13th: Code Sprint

 

See you in Portland,

logo_horiz_trans_150x69

FOSS4G PDX Local Organizing Committee

About FOSS4G

Put on by OSGeo, the annual FOSS4G conference is the premiere global gathering for people working with and creating open source geospatial software. It brings together developers, users, decision makers, and observers from a broad spectrum of organizations and fields of operation for six days of workshops, presentations, discussions, and cooperation. From this melting pot of great spatial ideas and industry flow numerous successful geospatial products, standards and protocols.

FOSS4G has been held all over the world and draws attendees from over 40 countries. Nottingham, England hosted the conference in 2013. In 2014, Portland, Oregon, USA will host FOSS4G’s tenth year.

About OSGeo

The Open Source Geospatial Foundation was founded in 2006 to support and build the highest-quality open source geospatial software. The foundation’s goal is to encourage the use and collaborative development of community-led projects, data development and education. Many projects live under the OSGeo umbrella, including FOSS4G. http://osgeo.org

About PDX OSGeo – Portland Area and Oregon OSGeo Chapter

The PDX-OSGeo chapter of OSGeo has been meeting, discussing and promoting the use of open source geospatial technology since 2009. Chapter members often organize or present on open source software at regional geospatial conferences. PDX is the airport code and like the PDX airport, the group has a wide catchment area.

Sponsors:

Silver Level Sponsors

boundless_logoesri_logo

 

Bronze Level Sponsors

azaveacartodb_150x53 logo_klein_foss4g

 

Supporters

AppGeoFOSS4G2014 camptocamp_logolocate-press-150mapgears_rgb_transparent_nb_150x81NBT_logo_150x60logo_terrestris

Media Partner


directionsmagazine_logo geoconnexion_logo Geospatial-World-FOSS4G-2014_v2-NEW- Logo GIM-voor drukkerkopie 150gis-news

GISusrNews  LBxJournal systems_and_sensors_logoslashgeo_logo VSlogobanner1_ 3dvisworld2800_square_trans_small2

 


For more information or to keep informed from the FOSS4G Organizing Committee, follow @foss4g on Twitter, subscribe to our announcements list, or contact: foss4g2014-info@osgeo.org

Darrell Fuhriman, Chair of the FOSS4G Organizing Committee, email: darrell@garnix.org

by Eli Adam at April 11, 2014 04:41 PM

GeoSolutions

Released the support for NGMP (NATO Geospatial Metadata Profile) in GeoNetwork

GeoNetwork

Dear all,

we have committed in the GeoNetwork official repository a schema plugin that deals with NGMP the Nato GeoSpatial Military Profile which is available here.

As you may know, GeoNetwork has introduced in v2.8 a mechanism for supporting pluggable schemas, that is:

A schema in GeoNetwork is a directory with stylesheets, XML schema descriptions (XSDs) and other information necessary for GeoNetwork to index, view and possibly edit content from XML metadata records. 

The XML records we are dealing with are metadata following the NGMP standard, an ISO19139 application profile developed by DGIWG and NATO in order to extend the information about accessibility, releasability and classification of the data. In our use case GeoNetwork is used as a backend for harvesting prepared metadata and expose them through a CSW endpoint; it means that no editing capabilities were required.

The workplan needed to create some templates with placeholders; such templates were then processed by custom scripts that, by replacing the placeholders with information extrapolated from the real data, generated the final metadata files to be ingested in GeoNetwork .   

Editing the metadata in GeoNetwork was not needed, but creating templates by hand is extremely error prone, so as a first step we implemented the validation part, by adding the NGMP schema and writing  Schematron rules to enforce some major constraints. This first step allowed us to validate the templates and also to check the validity of the processed metadata.

  1.  The ingested metadata need then to be published. Metadata dissemination is performedusing GeoNetwork itself as a viewer, so the related XSL presentation files have been developed
  2. through CSW: we implemented some conversion XSL files in order to present the metadata records as base ISO19139 records (e.g. mapping some NGMP specific codelist into keywords)
  3.  exporting the XML files from the GUI: we reused the XSL templates in order to offer both the NGMP record and the record "flattened" in plain ISO19139.

If you are interested in learning about how we can help you achieving your goals with our Open Source products and professional services, do not hesitate to contact us!

 The GeoSolutions team,

320x100_eng

by Emanuele Tajariol at April 11, 2014 03:31 PM

April 10, 2014

Faunalia

QGIS PT users group: Portuguese speaking community

It’s with an enormous pleasure that we announce what we believe to be a very important step for the QGIS Portuguese speaking community, the creation of the QGIS PT users group. The QGIS PT users group arise from the notorious growth of QGIS usage  in Portugal, with the objective of become a platform for sharing […]

by faunaliagis at April 10, 2014 04:42 PM

Boundless Blog

Support story: Deterministic rendering order in SLDs

MassGIS As with our first support story, this one comes from MassGIS, the official state agency assigned to the collection, storage, and dissemination of geographic data. When a layer has overlapping lines or polygons, we often want to control which ones are rendered on top and which ones are rendered below. The classic example is when we have a roads layer that contains overpasses that we want to appear above regular roads at ground level. MassGIS was dealing with a land-usage layer which required one type of polygon to be rendered with a solid color and other types to be rendered above with specific patterns.

The Aral Sea Example

We can simulate this problem by taking a layer that has both current and historical extents of bodies of water. In particular we’ll look at the Aral Sea, which shrunk considerably in the twentieth century. We’ll want to style the historical extents using hatching and then overlay the current lake in a plain blue style. What we don’t want is to have the historical bounds drawn over the modern lake.

You can test on your own GeoServer install with the data and SLDs in this ZIP.

SLD Rules

Our first attempt at creating an SLD to draw the two polygons in the correct order is to use two rule statements: the first will match our historical layer (where attribute type is equal to historical) and the second will match the modern layer (where the attribute type is equal to modern). We expect this to draw the historical lakes first and then the modern lakes on top:

<sld:StyledLayerDescriptor version="1.0.0" xmlns:sld="http://www.opengis.net/sld">
  <sld:NamedLayer>
    <sld:Name>Lakes</sld:Name>
    <UserStyle xmlns="http://www.opengis.net/sld">
      <FeatureTypeStyle>
        <Rule>
          <Name>Historical area</Name>
          ...
        </Rule>       
        <Rule>
          <Name>Modern area</Name>
          ...
        </Rule>
      </FeatureTypeStyle>
    </UserStyle>
  </sld:NamedLayer>
</sld:StyledLayerDescriptor>

Unfortunately, this gives us the opposite effect: the historical area has been rendered above the modern area.

Since this ordering of the rules didn’t work, we can try switching them around in the SLD, putting the rule for modern lakes first and historical lakes second. If you test this in GeoServer, however, you will see that the image that we get back is not affected.

Since reordering rules in an SLD does not affect the output image, we had to provide another approach.

SLD FeatureTypeStyle

The answer to the problem is to use the rules in separate <FeatureTypeStyle> sections of our SLD document:

<sld:StyledLayerDescriptor version="1.0.0" xmlns:sld="http://www.opengis.net/sld">
  <sld:NamedLayer>
    <sld:Name>Lakes</sld:Name>
    <UserStyle xmlns="http://www.opengis.net/sld">
      <FeatureTypeStyle>
        <Rule>
          <Name>Historical area</Name>
          ...
        </Rule>
      </FeatureTypeStyle>
      <FeatureTypeStyle>
        <Rule>
          <Name>Modern area</Name>
          ...
        </Rule>
      </FeatureTypeStyle>
    </UserStyle>
  </sld:NamedLayer>
</sld:StyledLayerDescriptor>

Why does this work?

Our first approach did not work since rules inside a single FeatureTypeStyle are applied to features as they arrive from the data source. GeoServer was drawing the modern Aral Sea first and the historical Aral Sea second simply because that is the order in which they were stored in the shapefile.

Even if the order had been correct, it would have been dangerous to rely on it for styling since that order could change at any time.

To reliably control the rendering order, therefore, we need the multiple FeatureTypeStyle blocks. GeoServer will draw each of these independently and then merge them in the defined order as the last step.

Benjamin Trigona-Harany leads our global support team from our offices in Victoria, BC. Interested in support or training for your enterprise? Contact us to learn more.

The post Support story: Deterministic rendering order in SLDs appeared first on Boundless.

by Benjamin Trigona-Harany at April 10, 2014 01:39 PM

GIS for Thought

UK Rail Network Visualized by Operator

The United Kingdom’s railway network is split up into regional franchises, these franchises are run by private companies who bid on the work. So for example ScotRail, which runs the trains in Scotland is owned by the FIrst Group, who also run a number of other regional franchises. This can however change, when the contracts are up for bid.

Interestingly there is also a governmental holding company (Directly Operated Railways), which can take over a franchise if necessary, they currently run East Coast Trains.

For this visualization I have grouped Serco-Abellio and Abellio as Serco/Abellio.

EDIT: Like mentioned in the Scotland to the Rest of the UK, lines are drawn between stations on a route. So a direct route from Glasgow to London would be a direct line between the two terminus stations.

UK Railway Network by Operator

Inspired by Scotland’s connections to the rest of the UK.

Data:

Train lines: GTFS Data Exchange

Country outline: Natural Earth

by Heikki Vesanto at April 10, 2014 08:00 AM

April 09, 2014

gvSIG Team

6as Jornadas gvSIG da América Latina e do Caribe: Workshop “Bacias hidrográficas”

A oficina a ser ministrada pelo prof. Gilberto Cugler sobre delimitação de bacias hidrográficas a ser realizada no evento MundoGEO#Connect Conferência e Feira de Geomática e Soluções Geoespaciais em conjunto com as 6as Jornadas da América Latina e do Caribe de gvSIG: “Inovação e desenvolvimento colaborativo: Superação e desafios” tem como objetivo mostrar a facilidade em gerar os limites de bacias e sub-bacias hidrográficas, utilizando as ferramentas incorporadas no gvSIG.

O exemplo prático será sobre uma área de aproximadamente 2000 km2 onde será delimitada a bacia do Rio Verde no município de Tapiraí estado de São Paulo/Brasil com extensão de 35 km e área de 317 km2. O processo de delimitação da bacia disponibilizará também a ordem de Strahler e outras informações que permitem fazer a análise morfométrica de uma bacia hidrográfica.

Os dados necessários para o exercício proposto estão em http://www.sigrb.com.br/capacitacao/6as_lac.php na opção 6as Jornadas da América Latina e do Caribe de gvSIG – 2014 / Detalhes conforme ilustra a figura.

LAC_Taller_Bacias

Lembramos que os inscritos para a oficina deverão trazer o seu notebook com o gvSIG e os dados previamente instalados.

Para facilitar o andamento do exercício a ser desenvolvido na oficina, solicitamos padronizar a pasta de trabalho, para isto, é necessário executar o arquivo gvSIG_1.11_SIG-RB_portable_PT_BR.exe aceitando como padrão a pasta proposta (SigRibeira) e posteriormente descompactar nesta pasta os dados (Dados_6LAC.zip).

Qualquer dificuldade em baixar os arquivos ou com os dados obtidos estaremos a disposição em sigrb@sigrb.com.br ou gilbertocugler@gmail.com .


Filed under: events, gvSIG Desktop, portuguese, training

by Alvaro at April 09, 2014 11:29 PM

BostonGIS

MySQL 5.7 GIS building on Boost Geometry

Interesting times ahead. The upcoming MySQL 5.7 promises to provide great enhancements in the spatial space. They've scrapped much of the existing GIS plumbing they have in place seen in prior 5.6 and are replacing muc of it with Boost Geometry. In addition R-Tree indexes will be available for InnoDb. Details: Why Boost.Geometry in MySQL? and Making use of Boost Geometry in MySQL. Along the roadmap (not for 5.7) they plan to have geography support as well and projections, 3D and the various output formats e.g GeoJSON currently available in PostGIS.

Just when I thought database spatial domain was getting boring. It will be interesting to see how the new MySQL Boost Geometry stacks against PostGIS GEOS /3D CGAL support. Might be time for a PostGIS/MySQL shoot-out soon.

by Regina Obe (nospam@example.com) at April 09, 2014 07:44 PM

April 08, 2014

OSGeo News

OSGeo Code Sprint 2014 in Vienna - A great success!

by aghisla at April 08, 2014 07:26 PM

Andrea Antonello

Geopaparazzi 3.9.4 is out

Yes, this is open source development.
You publish a release and after a week of development you feel you need to release again to have them all use the new stuff :)

So version 3.9.4 is out in the google play.

Quickly the news:

1) automatic center on gps is now also on map menu. This is nice if you need to turn it on quickly. You don't want to go all the way to the settings.

2) Fixes:

  • fix timestamp on log details in local time (was UTC)
  • fix for logging sometimes interrupting without apparent reason
  • fix for geopaparazzi not able to deliver SMS on android 4.4

3) Log analysis tool

This is the nice new entry.

Maybe not everyone knows that from the Secret View one can enable 3 levels of logging.



This gives the possibility to have a look at what happened and for example it helped me to solve the aforementioned problem with interruption of logs, since errors are always logged.

If you push the "analyze log" button, you will get:


You can select between different types of log message, of which the most importants might be E (error) and G (GPS related). The others would be I (info), CH (check), A (anomalies) and M (memory related), but they still have to be better defined.

Maybe this tool is more suited to developers than users, but I have seen some advanced users in the geopaparazzi mailinglists that I am sure will be fiddeling around with this.

Enjoy!


PS: remember to clear the log from time to time (clear log button in secret view).

There is also a related feature worth to mention: if you need to convert geopaparazzi data to GIS data, check out this short tutorial.





by andrea antonello (noreply@blogger.com) at April 08, 2014 09:57 AM

April 07, 2014

Boundless Blog

Use QGIS for the Bay Area Bike Share Open Data Challenge

Gretchen PetersonThe San Francisco Bay Area Bike Share Open Data Challenge is now underway, with entries due April 25, 2014. The idea is to use their open data on bike stations, bicycle traffic patterns, and weather to create an interesting visualization, map, or other product that adds value to the program.

Using open source mapping tools is a great way to explore the data and create winning entries for the contest. For those who are new to making maps out of open data, we’re here to help you get started. In this tutorial we’ll show you how to use QGIS, a popular mapping software product, to create a simple map out of the data. Build on this foundation to create your own contest entries and learn about data and geospatial technology along the way.

To get started, download all four data files from the contest website here. After you unzip the data you’ll see that it’s in CSV format. This is a comma delimited text file format that’s useful for spreadsheets and geospatial tables.

Installing QGIS

First, download and install QGIS. Then install the OpenLayers plugin, which simplifies adding some of the most common base layers, such as Google Maps or OSM, and makes it easier to visualize the bike station locations. You can install it by opening the Plugin Manager, selecting the Get more section and then searching for OpenLayers.

install_ol.png

Now in the Plugins menu you should have a new entry where you can select the layers to add.

openlayers.png

 

Adding bike share data

Add whichever basemap you like. In the following screenshots, you will see that we’ve added the Bing Road layer, which is less saturated than some of the others. A less saturated basemap helps to highlight the data that will be overlaid. You can zoom into San Francisco now or wait until the bike share data is added. To create the bike share data overlay, use the Add Delimited Text Layer button.

AddDelimitedTextLayer.png

Add the station data file using the browse button. Use the x and y drop down selectors under Geometry definition to tell QGIS which fields have the latitude coordinates and which have the longitude coordinates. Latitude is y and longitude is x.

DelimitedTextCreateLayer1.png

Your input should look like the screenshot above. Press OK. In the Coordinate Reference System Selector, type in “4326” in the Filter box and select WGS 84 in the box directly beneath it. Many — but not all — datasets in open data formats are in the WGS 84, or EPSG 4326, coordinate system.

DelimitedTextCreateLayer2.png

The QGIS map should now look similar to the screenshot below. If it isn’t zoomed in properly, you can right-click the station_data layer in the Layers list and choose Zoom to Layer Extent.

StationDots1.png

Joining and analyzing bike share data

There is a lot of data in the other three tables to explore but they need to be joined to the station data first since the station data contains the geometry for displaying the data on the map, while the other tables are related to the station data geometry via its station_id field. Fields that can be used for joining are often described in files that come with the data. The README.txt file that came with this data follows this convention.

In this tutorial we’ll use the trip_data table to perform an analysis and display the results on the map. First the trip_data table needs to be added to QGIS. Click Add Delimited Text Layer again, browse to the trip_data table, and choose “No geometry” next to Geometry layer definition. Press ok. The table is added to the Layers list in QGIS. Right-click the table name in the Layers list and click Open Attribute Table. You can see the data has loaded correctly. Notice that the station_id is used in the Start Terminal and End Terminal fields.

atttable.png

The average duration of a trip from each station is a good first analysis. To get the average duration we have to total up the durations of each trip by Start Terminal. This could be done in a spreadsheet program, exported as a CSV file, and then added into QGIS using the steps described above for loading non-spatial tables. Alternatively, we are providing avg.py, a script created that will do the calculation within QGIS.

In the Processing menu under Options and configuration, expand Scripts and view the folder path. This is the folder path in which to save the Python script. Once the script is saved to that path, restart QGIS.

Open the Processing Toolbox by clicking Processing > Toolbox. It will appear on the right-hand side of the QGIS window. Expand Scripts, Boundless, and double-click “avg.” Fill out the dialog with the following, making sure to save the table as a CSV file in the path of your choosing.

avgWindow.png

Now you can join the output table with the station data layer in order to visualize the average duration (in seconds) of trips from each station. Double-click the station_data layer in the Layers list to bring up the Properties window. Choose Joins and click the green plus sign near the bottom of the window. Pick the table from the list that contains the average data and the field that has the station ID number. If you used the QGIS script, these will be “output_table” and “class.” The Target field is “station_id.”

addvectorjoin.png

Now you can look at the attribute table for the station_data to make sure the join worked properly. If it did, the fields from station_data are now in the table. (If the fields are added to the table but the cells are populated with NULL values, the wrong id field was used in the join process.)

To visualize the duration field, double click the station_data in the Layers list to open the Layer Properties and choose Style. Choose Graduated, output_table_avg for the column to style, and change the color in the color ramp as per your preference. Change the mode to Natural Breaks and press ok. (Choosing a mode that makes sense for the data and for the map is an important part of the analytical process. Here is more information on modes).SmallScale1.png

Zoom in to the denser section to see that data more clearly. Enlarge the circles by double clicking station_data, Style, click the change symbol button and change the size to 3. Click OK twice.

LargeScale1.png

The trips in San Francisco appear to be shorter than the trips in Redwood City. Hopefully this tutorial on using QGIS with the Bay Area Bike Share open data provides a springboard for contest entrants. Good luck!

Interested in QGIS? Learn more at the first QGIS user group meetup in the United States on Friday, April 11!

The post Use QGIS for the Bay Area Bike Share Open Data Challenge appeared first on Boundless.

by Gretchen Peterson at April 07, 2014 02:07 PM

GIS for Thought

Public Transport Connections Between Scotland and the Rest of the UK

As a follow up to Scotland’s connections to outside the UK, here are the connections between Scotland and the rest of the UK. Missing is the bus network.

The train lines are drawn between stops on the route, so a direct train from London to Glasgow would be a straight line between the two terminus stations.

The real interesting thing is that there is a crosscountry train running from Glasgow to Penzance.

Transport_to_UK

Data sources:

Flights – OpenFlights.org

Trains – GTFS Data Exchange

Ferries - OpenStreetmap

Land – NaturalEarth

by Heikki Vesanto at April 07, 2014 11:00 AM

April 06, 2014

Even Rouault

GML madness

I am convinced that most people wonder "how many ways are there to encode a polygon in GML ?" If you have never considered that before, you might be interested in reading the following lines.

To start gently, let us consider the following grey shape :




Mathematicians call it a square, which is a particularly case of a rectangle, which is itself a polygon. A simple way of describing a polygon is to list the coordinates of its corners :



Corner 0 coordinates are (0,0)
Corner 1 coordinates are (0,1)
Corner 2 coordinates are (1,1)
Corner 3 coordinates are (1,0)
And Corner 4 = Corner 0

One of the most compact way of describing that polygon in GML 3.2 is the use of the gml:Polygon element :
<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                   http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:LinearRing>
            <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
        </gml:LinearRing>
    </gml:exterior>
</gml:Polygon>
We can forget the XML namespaces declaration and just concentrate on the fact that a Polygon is made of an exterior ring described by a list of positions. For those who wonder why we need to specify the "exterior", you must know that polygons may have holes in them, and those holes are called "interior rings", but we will not explore that level of complexity.

The documentation of the gml:LinearRing element shows that there are other ways of expressing the coordinates. We can isolate each corner in a separate gml:pos element :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                       http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:LinearRing>
            <gml:pos>0 0</gml:pos>
            <gml:pos>0 1</gml:pos>
            <gml:pos>1 1</gml:pos>
            <gml:pos>1 0</gml:pos>
            <gml:pos>0 0</gml:pos>
        </gml:LinearRing>
    </gml:exterior>
</gml:Polygon>

Or we can use a gml:Point inside a gml:pointProperty :
<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                    http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:LinearRing>
            <gml:pointProperty>
                <gml:Point gml:id="ID2">
                    <gml:pos>0 0</gml:pos>
                </gml:Point>
            </gml:pointProperty>
            <gml:pointProperty>
                <gml:Point gml:id="ID3">
                    <gml:pos>0 1</gml:pos>
                </gml:Point>
            </gml:pointProperty>
            <gml:pointProperty>
                <gml:Point gml:id="ID4">
                    <gml:pos>1 1</gml:pos>
                </gml:Point>
            </gml:pointProperty>
            <gml:pointProperty>
                <gml:Point gml:id="ID5">
                    <gml:pos>1 0</gml:pos>
                </gml:Point>
            </gml:pointProperty>
            <gml:pointProperty>
                <gml:Point gml:id="ID6">
                    <gml:pos>0 0</gml:pos>
                </gml:Point>
            </gml:pointProperty>
        </gml:LinearRing>
    </gml:exterior>
</gml:Polygon>
Those who carefully look at the above snippet realize that the content of the last pointProperty is the same as the first one. So we can use xlink:href power to optimize that a bit :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xmlns:xlink="http://www.w3.org/1999/xlink"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                   http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:LinearRing>
            <gml:pointProperty>
                <gml:Point gml:id="ID2">
                    <gml:pos>0 0</gml:pos>
                </gml:Point>
            </gml:pointProperty>
            <gml:pointProperty>
                <gml:Point gml:id="ID3">
                    <gml:pos>0 1</gml:pos>
                </gml:Point>
            </gml:pointProperty>
            <gml:pointProperty>
                <gml:Point gml:id="ID4">
                    <gml:pos>1 1</gml:pos>
                </gml:Point>
            </gml:pointProperty>
            <gml:pointProperty>
                <gml:Point gml:id="ID5">
                    <gml:pos>1 0</gml:pos>
                </gml:Point>
            </gml:pointProperty>
            <gml:pointProperty xlink:href="#ID2"/>
        </gml:LinearRing>
    </gml:exterior>
</gml:Polygon>
People nostalgic of the GML 2.1.2 era will probably want to use the now deprecated (but still valid) gml:coordinates element :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                    http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:LinearRing>
        <!-- deprecated -->
            <gml:coordinates>0,0 0,1 1,1 1,0 0,0</gml:coordinates>
        </gml:LinearRing>
    </gml:exterior>
</gml:Polygon>
We could play with cs (coordinate separator) and ts (tuple separator) attributes of gml:coordinates to generate alternate encoding for the coordinate list, but we will not do that. Enough with deprecated features ! Let us concentrate on modernity.

Our shape is a gml:Rectangle, isn'it ?
<?xml version="1.0"?>
<gml:Rectangle xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                 http://schemas.opengis.net/gml/3.2.1/gml.xsd">
    <gml:exterior>
        <gml:LinearRing>
            <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
        </gml:LinearRing>
    </gml:exterior>
</gml:Rectangle>
Careful observers will notice that we have not simply substituted Polygon by Rectangle, but we have also removed the gml:id attribute. Why so ? Because a Polygon is a first citizen GML object deriving from gml:AbstractGMLType, whereas Rectangle just derives from gml:AbstractSurfacePatchType. Poor gml:Rectangle... We will come back to it later.

Until now, we have restricted the interior to be a LinearRing. But a LinearRing is a particular case of a gml:Ring :
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                  http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:Ring>
            <gml:curveMember>
                <gml:LineString gml:id="ID2">
                    <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
                </gml:LineString>
            </gml:curveMember>
        </gml:Ring>
    </gml:exterior>
</gml:Polygon>
As before we can use a series of gml:pos instead of gml:posList :
<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                 http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:Ring>
            <gml:curveMember>
                <gml:LineString gml:id="ID2">
                    <gml:pos>0 0</gml:pos>
                    <gml:pos>0 1</gml:pos>
                    <gml:pos>1 1</gml:pos>
                    <gml:pos>1 0</gml:pos>
                    <gml:pos>0 0</gml:pos>
                </gml:LineString>
            </gml:curveMember>
        </gml:Ring>
    </gml:exterior>
</gml:Polygon>
But we could also use several gml:curveMember with a simple 2-point gml:LineString :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:Ring>
            <gml:curveMember>
                <gml:LineString gml:id="ID2">
                    <gml:posList>0 0 0 1</gml:posList>
                </gml:LineString>
            </gml:curveMember>
            <gml:curveMember>
                <gml:LineString gml:id="ID3">
                    <gml:posList>0 1 1 1</gml:posList>
                </gml:LineString>
            </gml:curveMember>
            <gml:curveMember>
                <gml:LineString gml:id="ID4">
                    <gml:posList>1 1 1 0</gml:posList>
                </gml:LineString>
            </gml:curveMember>
            <gml:curveMember>
                <gml:LineString gml:id="ID5">
                    <gml:posList>1 0 0 0</gml:posList>
                </gml:LineString>
            </gml:curveMember>
        </gml:Ring>
    </gml:exterior>
</gml:Polygon>
Instead of a single gml:LineString, we could use a more powerful gml:Curve :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                  http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:Ring>
            <gml:curveMember>
                <gml:Curve gml:id="ID2">
                    <gml:segments>
                        <gml:LineStringSegment>
                            <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
                        </gml:LineStringSegment>
                    </gml:segments>
                </gml:Curve>
            </gml:curveMember>
        </gml:Ring>
    </gml:exterior>
</gml:Polygon>
But it is a bit of a shame to use a single gml:LineStringSegment inside a gml:segments. Let us fix that :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                   http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:Ring>
            <gml:curveMember>
                <gml:Curve gml:id="ID2">
                    <gml:segments>
                        <gml:LineStringSegment>
                            <gml:posList>0 0 0 1</gml:posList>
                        </gml:LineStringSegment>
                        <gml:LineStringSegment>
                            <gml:posList>0 1 1 1</gml:posList>
                        </gml:LineStringSegment>
                        <gml:LineStringSegment>
                            <gml:posList>1 1 1 0</gml:posList>
                        </gml:LineStringSegment>
                        <gml:LineStringSegment>
                            <gml:posList>1 0 0 0</gml:posList>
                        </gml:LineStringSegment>
                    </gml:segments>
                </gml:Curve>
            </gml:curveMember>
        </gml:Ring>
    </gml:exterior>
</gml:Polygon>
Of course we can still use gml:pointProperty to avoid repeating the same coordinate tuples :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xmlns:xlink="http://www.w3.org/1999/xlink"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:Ring>
            <gml:curveMember>
                <gml:Curve gml:id="ID2">
                    <gml:segments>
                        <gml:LineStringSegment>
                            <gml:pointProperty>
                                <gml:Point gml:id="ID3">
                                    <gml:pos>0 0</gml:pos>
                                </gml:Point>
                            </gml:pointProperty>
                            <gml:pointProperty>
                                <gml:Point gml:id="ID4">
                                    <gml:pos>0 1</gml:pos>
                                </gml:Point>
                            </gml:pointProperty>
                        </gml:LineStringSegment>
                        <gml:LineStringSegment>
                            <gml:pointProperty xlink:href="#ID4"/>
                            <gml:pointProperty>
                                <gml:Point gml:id="ID5">
                                    <gml:pos>1 1</gml:pos>
                                </gml:Point>
                            </gml:pointProperty>
                        </gml:LineStringSegment>
                        <gml:LineStringSegment>
                            <gml:pointProperty xlink:href="#ID5"/>
                            <gml:pointProperty>
                                <gml:Point gml:id="ID6">
                                    <gml:pos>1 0</gml:pos>
                                </gml:Point>
                            </gml:pointProperty>
                        </gml:LineStringSegment>
                        <gml:LineStringSegment>
                            <gml:pointProperty xlink:href="#ID5"/>
                            <gml:pointProperty xlink:href="#ID3"/>
                        </gml:LineStringSegment>
                    </gml:segments>
                </gml:Curve>
            </gml:curveMember>
        </gml:Ring>
    </gml:exterior>
</gml:Polygon>
Another child element of gml:curveMember is a gml:CompositeCurve :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                   http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:Ring>
            <gml:curveMember>
                <gml:CompositeCurve gml:id="ID2">
                    <gml:curveMember>
                        <gml:LineString gml:id="ID3">
                            <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
                        </gml:LineString>
                    </gml:curveMember>
                </gml:CompositeCurve>
            </gml:curveMember>
        </gml:Ring>
    </gml:exterior>
</gml:Polygon>
But, you may have noticed that the child of a CompositeCurve is a curveMember, which is also the parent of the CompositeCurve. So we may put a CompositeCurve inside a CompositeCurve :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:Ring>
            <gml:curveMember>
                <gml:CompositeCurve gml:id="ID2">
                    <gml:curveMember>
                        <gml:CompositeCurve gml:id="ID3">
                            <gml:curveMember>
                                <gml:LineString gml:id="ID4">
                                    <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
                                </gml:LineString>
                            </gml:curveMember>
                        </gml:CompositeCurve>
                    </gml:curveMember>
                </gml:CompositeCurve>
            </gml:curveMember>
        </gml:Ring>
    </gml:exterior>
</gml:Polygon>
You have probably understood now that we could nest CompositeCurve as many times as wished. So we have now the answer to the initial question : there is an infinity of ways of expressing a polygon in GML 3.2 !

Another child element of gml:curveMember is a gml:OrientableCurve :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:Ring>
            <gml:curveMember>
                <gml:OrientableCurve gml:id="ID2">
                    <gml:baseCurve>
                        <gml:LineString gml:id="ID3">
                            <gml:pos>0 0</gml:pos>
                            <gml:pos>0 1</gml:pos>
                            <gml:pos>1 1</gml:pos>
                            <gml:pos>1 0</gml:pos>
                            <gml:pos>0 0</gml:pos>
                        </gml:LineString>
                    </gml:baseCurve>
                </gml:OrientableCurve>
            </gml:curveMember>
        </gml:Ring>
    </gml:exterior>
</gml:Polygon>
But the full power of OrientableCurve is to be able to express the orientation of the curve. So let us split the ring into 2 pieces, one with positive orientation and one with negative orientation :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                 http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:Ring>
            <gml:curveMember>
                <gml:OrientableCurve gml:id="ID2">
                    <gml:baseCurve>
                        <gml:LineString gml:id="ID3">
                            <gml:pos>0 0</gml:pos>
                            <gml:pos>0 1</gml:pos>
                            <gml:pos>1 1</gml:pos>
                        </gml:LineString>
                    </gml:baseCurve>
                </gml:OrientableCurve>
            </gml:curveMember>
            <gml:curveMember>
                <gml:OrientableCurve gml:id="ID4" orientation="-">
                    <gml:baseCurve>
                        <gml:LineString gml:id="ID5">
                            <gml:pos>0 0</gml:pos>
                            <gml:pos>1 0</gml:pos>
                            <gml:pos>1 1</gml:pos>
                        </gml:LineString>
                    </gml:baseCurve>
                </gml:OrientableCurve>
            </gml:curveMember>
        </gml:Ring>
    </gml:exterior>
</gml:Polygon>
Enough with polygons. A polygon is just a particular case of a gml:Surface :

<?xml version="1.0"?>
<gml:Surface xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                     http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:patches>
        <gml:PolygonPatch>
            <gml:exterior>
                <gml:LinearRing>
                    <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
                </gml:LinearRing>
            </gml:exterior>
        </gml:PolygonPatch>
    </gml:patches>
</gml:Surface>

Instead of a gml:PolygonPatch as a child of a gml:patches, we can use the gml:Rectangle we have used before :

<?xml version="1.0"?>
<gml:Surface xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                   http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:patches>
        <gml:Rectangle>
            <gml:exterior>
                <gml:LinearRing>
                    <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
                </gml:LinearRing>
            </gml:exterior>
        </gml:Rectangle>
    </gml:patches>
</gml:Surface>
A Surface seems to be too simple. Why not using a gml:CompositeSurface ?

<?xml version="1.0"?>
<gml:CompositeSurface xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                   http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:surfaceMember>
        <gml:Surface gml:id="ID2">
            <gml:patches>
                <gml:PolygonPatch>
                    <gml:exterior>
                        <gml:LinearRing>
                            <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
                        </gml:LinearRing>
                    </gml:exterior>
                </gml:PolygonPatch>
            </gml:patches>
        </gml:Surface>
    </gml:surfaceMember>
</gml:CompositeSurface>
But it looks a bit dumb to use only one gml:surfaceMember. Let us divide our square into 2 triangles :

<?xml version="1.0"?>
<gml:CompositeSurface xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                     http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:surfaceMember>
        <gml:Surface gml:id="ID2">
            <gml:patches>
                <gml:PolygonPatch>
                    <gml:exterior>
                        <gml:LinearRing>
                            <gml:posList>0 0 0 1 1 1 0 0</gml:posList>
                        </gml:LinearRing>
                    </gml:exterior>
                </gml:PolygonPatch>
            </gml:patches>
        </gml:Surface>
    </gml:surfaceMember>
    <gml:surfaceMember>
        <gml:Surface gml:id="ID3">
            <gml:patches>
                <gml:PolygonPatch>
                    <gml:exterior>
                        <gml:LinearRing>
                            <gml:posList>0 0 1 1 1 0 0 0</gml:posList>
                        </gml:LinearRing>
                    </gml:exterior>
                </gml:PolygonPatch>
            </gml:patches>
        </gml:Surface>
    </gml:surfaceMember>
</gml:CompositeSurface>
Instead of a gml:CompositeSurface, why not using a gml:MultiSurface ?

<?xml version="1.0"?>
<gml:MultiSurface xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                      http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:surfaceMember>
        <gml:Surface gml:id="ID2">
            <gml:patches>
                <gml:PolygonPatch>
                    <gml:exterior>
                        <gml:LinearRing>
                            <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
                        </gml:LinearRing>
                    </gml:exterior>
                </gml:PolygonPatch>
            </gml:patches>
        </gml:Surface>
    </gml:surfaceMember>
</gml:MultiSurface>
or maybe you prefer to use gml:surfaceMembers (with a final 's') instead of a gml:surfaceMember :

<?xml version="1.0"?>
<gml:MultiSurface xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                       http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:surfaceMembers>
        <gml:Surface gml:id="ID2">
            <gml:patches>
                <gml:PolygonPatch>
                    <gml:exterior>
                        <gml:LinearRing>
                            <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
                        </gml:LinearRing>
                    </gml:exterior>
                </gml:PolygonPatch>
            </gml:patches>
        </gml:Surface>
    </gml:surfaceMembers>
</gml:MultiSurface>

Similarly to gml:CompositeCurve, we can arbitrary nest as many gml:CompositeSurface as wished :

<?xml version="1.0"?>
<gml:CompositeSurface xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                 http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:surfaceMember>
        <gml:CompositeSurface gml:id="ID2">
            <gml:surfaceMember>
                <gml:Surface gml:id="ID3">
                    <gml:patches>
                        <gml:PolygonPatch>
                            <gml:exterior>
                                <gml:LinearRing>
                                    <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
                                </gml:LinearRing>
                            </gml:exterior>
                        </gml:PolygonPatch>
                    </gml:patches>
                </gml:Surface>
            </gml:surfaceMember>
        </gml:CompositeSurface>
    </gml:surfaceMember>
</gml:CompositeSurface>
So we have now two different kind of infinities ! That we could combine together. But, do not hope to have discovered more ways of expressing polygons. The cardinality of the set of natural numbers times the set of natural numbers ( N x N ) is just the cardinality of the set of natural numbers...

To conclude, we should mention that the authors of the GML specification have admitted that encoding polygons was a bit too complicated. So they have invented a "compact encoding" in the extended schemas of GML 3.3 :

<?xml version="1.0"?>
<gmlce:SimplePolygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:gmlce="http://www.opengis.net/gml/3.3/ce"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                    http://schemas.opengis.net/gml/3.2.1/gml.xsd
                    http://www.opengis.net/gml/3.3/ce
                    http://schemas.opengis.net/gml/3.3/geometryCompact.xsd"
             gml:id="ID1">
    <!-- we may, or not, close the ring -->
    <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
</gmlce:SimplePolygon>
But our SimplePolygon is indeed a SimpleRectangle. So let us use instead :

<?xml version="1.0"?>
<gmlce:SimpleRectangle xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:gmlce="http://www.opengis.net/gml/3.3/ce"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                    http://schemas.opengis.net/gml/3.2.1/gml.xsd
                    http://www.opengis.net/gml/3.3/ce
                    http://schemas.opengis.net/gml/3.3/geometryCompact.xsd"
             gml:id="ID1">
    <!-- caution : we should NOT clause with the first vertex ! -->
    <gml:posList>0 0 0 1 1 1 1 0</gml:posList>
</gmlce:SimpleRectangle>
You can found the above 25 snippets at the following URL : http://even.rouault.free.fr/gml/
They are all valid GML 3.2 snippets that validate the XML schemas and pass the GML 3.2 Conformance Test Suite (except gml4.xsd which uses the deprecated gml:coordinates element).

Oh, final fun, as GML is XML, we can also use XML substitutable entities ...

<?xml version="1.0"?>
<!DOCTYPE points [
 <!ENTITY pt0 "0 0">
 <!ENTITY pt1 "0 1">
 <!ENTITY pt2 "1 1">
 <!ENTITY pt3 "1 0">
]>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                     http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:LinearRing>
            <gml:posList>&pt0; &pt1; &pt2; &pt3; &pt0;</gml:posList>
        </gml:LinearRing>
    </gml:exterior>
</gml:Polygon>
Those who wonder why I decided to write this article might want to have a look at the following simplified GML sample of a real-world use case where a PolygonPatch has only an interior ring (a hole), but no exterior ring... Standalone holes : interesting concept, isn't it ?



by Even Rouault (noreply@blogger.com) at April 06, 2014 02:50 PM

Jody Garnett

2014 Events

Upcoming Events

GeoRabble All Stars (April 7th)

If you are in Canberra for Locate14 conference stop by GeoRabble All Stars for a diverse lineup of speakers (and me). GeoRabble events are always a good time and registration is free. Thanks to LocationTech and Boundless for sponsoring.

Location Intelligence (May May 19-21)

If you are in Washington for Location Intelligence I will be helping out with one of the workshops and would love to see you there!

FOSS4G (Sept 8th-13th)

If you are in Portland for FOSS4G be sure to sign up now an register for workshops while there are spots open!

I will be attending with two workshops: A fun session on GeoServer Cartography and Styling for anyone who has struggled with SLD. For the developers out there I was finally brave enough to submit a GeoTools DataStore Workshop.

Past Events

GeoNext (Feb 26)

Sadly you have missed this one, but it was a really good (and thought provoking) single day event. There is something magical about high quality event that is over in a day, no loss of momentum!

Eclipse Developer Day Sydney (April 2)

An interesting introduction to Eclipse Foundation culture, with a bit of mapping on the side.


by Jody Garnett (noreply@blogger.com) at April 06, 2014 12:23 PM

gvSIG Team

Programa Jornadas gvSIG de Latinoamérica e Caribe

0_LACJá assinalamos, em diversas ocasiões, o caráter especial (e espacial) que têm as Jornadas gvSIG de Latinoamérica e Caribe deste ano, que junto a MundoGEO#Connect constituem um ponto de encontro quase obrigatório da comunidade geo da América Latina.

Desde alguns dias atrás está disponível o programa das Jornadas, no qual podemos encontrar um amplo conjunto de apresentações, de variedade temática e geográfica, que são representativas da diversidade de áreas as quais gvSIG se aplica atualmente, desde o setor petroleiro à criminologia, passando pela gestão municipal ou de bacias hidrográficas, apresentações nas quais introduziremos as últimas novidades da tecnologia que se impulsiona desde a Associação gvSIG e os desafios que nos colocamos para o futuro. Tudo isso complementado com 3 oficinas, onde os usuários poderão aprender a manusear o gvSIG e aplicá-lo a distintos usos.

Fechando as jornadas, teremos uma mesa redonda que tratará de forma clara e direta das relações entre soberania tecnológica e software livre em Latinoamérica.

Mas, acima de tudo, as jornadas serão o ponto de encontro da Comunidade gvSIG, um espaço de colaboração e solidariedade em torno no conhecimento compartilhado.

A inscrição a todas as atividades das jornadas é totalmente gratuita e deve ser feita por meio da web do evento. No entanto, a capacidade é limitada, e não seriam as primeiras jornadas nas quais penduraríamos o cartaz de “Lotação completa”.


Filed under: community, events, gvSIG Desktop, i3Geo, portuguese, press office

by Alvaro at April 06, 2014 08:04 AM

April 04, 2014

Free and Open Source GIS Ramblings

Using OSM POIs in QGIS

Extracting POIs from OpenStreetMap is reasonably simple using Overpass API. A very convenient way to construct the query is to use a query builder which allows you to select the area of interest and builds queries for different servers.

xapi_query_builder

Of course you can fine-tune the query further. For example, you can add multiple key-value pairs to the query. I used the following query to select all Billa supermarkets:

http://www.overpass-api.de/api/xapi?*[shop=supermarket][name=Billa][bbox=15.96725,48.0432,16.79947,48.40915]

Note to * in the query? It means that I’m querying all kinds of features: nodes, ways, and relations.

Save the server response to a .osm file. This file can be loaded into QGIS using simple drag-and-drop or Add Vector Layer. A dialog will open where you can select the type of features you want to load from the file. You can simply use Select All and OK to load everything.

add_osm_file

My supermarket POIs came in two types: points and multipolygons. To style them both with nice supermarket SVG icons, I decided to use a Centroid fill with the SVG marker for the polygon layer:

osm_pois_billa

Open data and open source GIS … nice :-)


by underdark at April 04, 2014 09:41 PM

gvSIG Team

gvSIG 2.1 RC1

The first gvSIG 2.1 Release Candidate (gvSIG 2.1 RC1) is now available.

We encourage you to test it and send us any errors and suggestions in the users mailing list or directly in the bugtracker (see interesting links for testers).

It includes small improvements, most of which are not perceptible at a user level. It also has new features like georeferencing, seven new types of legend, advanced labeling, kml exporting, PostGIS 2 (vector & raster) supporting, raster supporting for scripting…

The list of the main new features of gvSIG 2.1 can be consulted on:
http://www.gvsig.org/web/projects/gvsig-desktop/official/gvsig-2.1/notas-de-version/new-features

Thanks for your collaboration!

—-

Ya está disponible gvSIG 2.1 RC1, la primera distribución candidata a versión (Release Candidate) de gvSIG 2.1.

Os animamos a que la probéis y a que nos reportéis los posibles errores y sugerencias que encontréis, ya sea a través de la lista de usuarios o directamente en el bugtracker (consultar enlaces de interés para testers).

gvSIG 2.1 además de mejoras menores, muchas de ellas no perceptibles a nivel de usuario, trae un considerable conjunto de novedades como georreferenciación, 7 nuevos tipos de leyendas, etiquetado avanzado, exportación a kml, soporte a postgis 2 (vectorial y raster), soporte a raster para scripting, etc.

La lista completa de novedades de la versión 2.1 pueden consultarse en:
http://www.gvsig.org/web/projects/gvsig-desktop/official/gvsig-2.1/notas-de-version/novedades

¡Gracias por vuestra colaboración!


Filed under: english, gvSIG Desktop, press office, spanish, testing

by Alvaro at April 04, 2014 07:49 AM

April 03, 2014

Boundless Blog

Boundless Connections: Matt Richards

Matt RichardsWe’re happy to welcome Matt Richards, our new web designer, to the team! Matt will be working from our brand new (and growing) DC office where he’ll be crafting interfaces and developing the user experience for hosted services like Mapmeter and other upcoming products.

Hi Matt. Welcome to Boundless! What were you doing before you joined us?

Most recently, I was at Cvent, a software-as-a-service company that has a platform for event management services. Think of it as Eventbrite for small-to-large businesses who host large events like conferences, meetings, company events, and tradeshows. Cvent manages and automates the more mundane aspects of logistics, marketing, and management for the entire event process.

While there, I worked as a web designer on the marketing team, so my projects were all public-facing. From landing pages, to new product announcements, to complete branding packages, my role was part visual design, part web development, and part creative guru. I led the design and development for Cvent’s most recent marketing project, the CrowdTorch website.

Before all of that though, I began my web design career at the ripe age of 16 in rural West Virginia.

You started a web design company prior to starting college?

There’s not a whole lot to do in West Virginia. <laughs> I stress that I lived in a very rural part of the state and wanted to do something cool out there. When I was younger, I ended getting into the competitive gaming scene. I designed graphics for gaming tournaments, leagues, and that sort of thing. From there I built up word-of-mouth referrals to build my client database, and I also did a lot of client work online.

Around the time I turned 16, I had enough of a client list and enough freelancers in my stable that I made an actual go of it. I registered as a business, began working with local and regional clients and had some pretty good successes along the way. I worked with developers — they do the programming and I would make it look cool. I built out websites, invitations, and collateral for gaming challenges. I was also building online networks for the competitive gaming scene. I became a well-known graphic designer within the gaming circle.

What excites you most about working on the new tools and products that Boundless is currently developing?

With an upcoming product that is taking on a new space in the market, I have the unique opportunity to design an interface and experience that isn’t really constrained by older, out-dated processes. This is really exciting as a designer — it means you can embrace the most recent design ideas and create a new user experience from the ground up. I’m really excited to start making what’ll hopefully be the best looking Boundless product to date.

What are your design resources and sources of inspiration?

Two pillars of the web design community are A List Apart and Smashing Magazine, both blogs I read regularly and find very useful. Some of the most interesting stuff I’ve seen recently has come out of Medium, specifically the Design/UX section. There’s a ton of other stuff scattered around though and I use sidebar.io and Panda to filter through the nonsense and find the best articles. I like to keep current.

What languages or programs are your main ways of working?

As a visual designer, I’m an expert at Photoshop use it quite frequently. But I’m also good at designing using HTML5, Canvas, and CSS3. I also have a some Javascript experience, namely jQuery. I’m also big into the principles of responsive design — all of my designs for the last year have been fully responsive. One area that I haven’t had a lot of experience is Less, but I’m excited to be using it at Boundless.

Do you have any experience with open source development?

I’m limited in this regard. I was exposed early on to the virtues of open source from my Dad, who was a passionate open source developer. I remember that he was always on Slashdot — this was back in the days when Slashdot was just the worst looking website around. <laughs> He was really passionate about using open source tools and was a big Linux advocate. I was very pro-Windows in those days, due mostly to my interest in gaming. I just didn’t have the appreciation for anything beyond the Windows gaming world back then. But now that I’m older I can see what my dad was excited about it. I’m really excited to be at a company that has open source values.

What do open source values means to you?

To me, it means the willingness to select tools and components that are the right ones for the task at hand. At proprietary companies, I see that there is more of a business decision process that leads development. That leads to tools and solutions being chosen based on political or cultural factors. Boundless seems to have a strong culture of embracing the best ideas and products and using the right tools for the job. An open source foundation provides a lot more flexibility and control.

What has been your favorite project to have worked on?

Professionally, my favorite project was the company career microsite for Cvent. I was able to go off-brand with colors and treatments, which was a satisfying technical and aesthetic challenge. There is a lot of video and photo assets that I incorporated into the site and I was able to make it more friendly and approachable than the typical branding was. It was immensely satisfying being able to stretch my design wings.

Another project that I really enjoyed working on was a the full brand build-out for CrowdTorch. I worked on the color, typography, icons, website design, and development. It was a really exciting project, because most what resulted was stuff that I conceptualized, designed, and eventually developed.

What’s an interesting facts about yourself (that you haven’t already said)?

When I was 15 years old, my family moved out to middle of nowhere: Thomas, West Virginia. Our parents decided to homeschool my two sisters and me. As part of that, we opened a music venue and cafe called The Purple Fiddle in an old general store. It was a bar/cafe/performing space in a small town. It was a much-needed venue for the area. The town had a population of about 250 people, and basically cafe was the highlight of the area’s entertainment.

For those of us not familiar with competitive online gaming, what are some popular trends right now?

There’s a growing industry known as “esports” that basically boils down to a bunch of gamers sitting in a room and playing video games — mostly Starcraft II, Defense of the Ancients 2, League of Legends, and Counter-Strike: Global Offensive. It doesn’t sound that competitive or interesting, but I assure you it is. At the largest tournaments, tens of millions of people tune in to watch gamers from all over the world compete for millions of dollars in prize money.  The numbers can be staggering at times; the biggest live viewership was 32 million. In comparison, NBA games usually get under 2 million viewers. It’s a bit crazy to comprehend how much it’s grown, but the scene is exploding and I was happy to be a part of it during it’s early stages.

What other hobbies do you have?

I’m a creative at heart, so my hobbies are basically just other creative outlets. I’m a DSLR geek, so I take photography whenever the opportunity arises. Even though there’s not much on it yet, I do plan on posting more photography to my 500px profile. I’ve also made quite a few short films. Here’s a few videos I’ve been proud of: an indie-rock music video, a short film about finding yourself (won an award!), and a trailer for an utopian sci-fi film that never was finished.

 Interested in joining Boundless? We have an amazing team of passionate, creative, and incredibly bright people and we’re hiring more!

The post Boundless Connections: Matt Richards appeared first on Boundless.

by Anthony Denaro at April 03, 2014 02:45 PM

gvSIG Team

Jornadas Mexicanas de gvSIG (Actualización)

inicioDebido al éxito de inscripciones de las 1as Jornadas Mexicanas de gvSIG, se han realizado algunas modificaciones en el programa preliminar para dar cabida a todas las personas inscritas en las mismas y disponer para el mayor número de interesados de la posibilidad de acceder a los talleres, ampliando con un nuevo taller de “Introducción a gvSIG” que se replicará tanto el jueves por la tarde como el viernes. De este modo, además de las ponencias, el programa de actividades se completará con un curso y seis talleres.

Así mismo se ha cambiado la sede de las sesiones de ponencias, que tendrán lugar en el Auditorio “Ignacio Ramírez” de la Facultad de Ciencias Políticas. Los talleres se mantienen en la Facultad de Geografía (entre ambas sedes hay unos 5 minutos andando).

Gracias a todos por hacer de estas jornadas un éxito.

Se puede consultar el programa actualizado en:  http://www.gvsig.org/web/community/events/jornadas-mexico/2014/Programa


Filed under: community, events, press office, spanish

by Alvaro at April 03, 2014 12:55 PM

GIS for Thought

Scotland’s Connections to the Wider World

On the verge of the Scottish vote for independence here is a look at all of the scheduled passenger connections between Scotland and outside of the UK. As it is, there are only flights. There are a few ferries between Northern Ireland and Scotland, however NI is still within the UK. No conclusions just an interesting visualisation.

Flights from Scotland to outside the UK

Thanks to:

The World Is A Village - PostGIS: using latitude and longitude to create geometry

Anita Graser - Visualizing Global Connections

Data from:

Natural Earth

OpenFlights

by Heikki Vesanto at April 03, 2014 11:00 AM

Christoph Baudson

Four day work week

I have been working 5 day weeks for 8 years now, without a significant pause. Since then I had very little time to pursue spontaneous interests in order to satisfy my curious nature. The plan So, in 2012, I challenged myself to take on an experiment: Do not spend my allotted days off on weeks of…

April 03, 2014 12:00 AM

April 02, 2014

Jackie Ng

Announcing: mapguide-rest 0.6

Here's the first release of mapguide-rest

And a general disclaimer: This is still work-in-progress code that's not ready for production use. However, that shouldn't stop you from downloading this release and having a play around :)

I have a bunch of mapguide-rest related posts in the draft queue, but it helps to have an accessible release as a point of reference for these posts rather than tell you to get the latest git clone of mapguide-rest.

One thing that stands out in this release since the initial announcement is the introduction of integrated REST API documentation.

What? REST API documentation? Aren't RESTful APIs self-describing, self-documenting and all this other stuff?

That may be true in an ideal sense, but pragmatism trumps idealism. mapguide-rest is the GET/POST/PUT/DELETE to a set of well-crafted URLs variety of REST API. In such cases, it definitely helps to know the definitive list of allowed URLs you can make requests to and the documented parameters that are allowed for each URLs.

So this is what we've provided for you. The documentation can be accessed at the following URL:

http://yourservername/mapguide/rest/doc/index.html

But this isn't a static document.


It's a fully interactive one!


The interactivity allows you to fully explore the REST API in a very intuitive fashion.

All this was made possible with the use of the Swagger documentation framework. The API reference is built on a modified version of Swagger UI. I've found Swagger to be a wonderful tool for generating REST API documentation. The initial set up takes some effort, but the pay-off of the final result is so worth it!

So now that we have a release on the board, stay tuned for more about the GeoREST-style data publishing framework.

Download

by Jackie Ng (noreply@blogger.com) at April 02, 2014 02:33 PM

Boundless Blog

GeoGit for Python: Announcing geogit-py

Victor OlayaAt Boundless, we usually describe GeoGit not as an application itself, but as a library. We see it as a basic component of geospatial data management on top of which other applications can be built. While GeoGit currently has a command-line interface (CLI), adding new ways of interacting with GeoGit will increase the possibilities for creating new projects that rely on GeoGit to manage changes to geospatial data. We hope to see GeoGit as the core of an ecosystem of tools that solve a variety of problems.

We have started developing a Python library, the geogit-py library, to make it much easier to create GeoGit-based applications. Since Python is a widespread scripting language, this will allow other developers to incorporate GeoGit-based capabilities into many other applications. In fact, we are already using it to create a plugin to bring the versioning capabilities of GeoGit into QGIS.

Basic GeoGit Automation

The geogit-py library will also make it easier to automate tasks when working with a GeoGit repository, since all the great features of the Python language can be used alongside GeoGit methods. This represents a great feature for all GeoGit users, especially those that use it in a workflow that can be partially of fully automated.

Here are some examples to provide an idea of what using the library is like. A basic workflow should start with something like this:

# Create repo
repo = Repository('path/to/repo/folder', init = True)

# Configure
repo.config(geogit.USER_NAME, 'myuser')
repo.config(geogit.USER_EMAIL, 'myuser@mymail.com')

# Add some data and create a snapshot
repo.importshp('myshapefile.shp')
repo.addandcommit('first import')

You can automate this first step and easily import a set of layers , creating a different snapshot for each one. Assuming that we have a set of shapefiles in a folder, the following code will do it.

for f in os.listdir(folder):
if f.endswith('.shp'):
   path = os.path.join(folder, f)
   repo.importshp(path)
   repo.addandcommit('Imported ' + f)

Editing Features

In a normal GeoGit workflow, you export from a GeoGit repository, edit the exported data using the tool of your choice (i.e. a desktop GIS like QGIS), and then import the changed layer so GeoGit can compute the changes that have been introduced, which are later used to create a new snapshot.

With geogit-py, that approach is still possible, but you can also edit without exporting while directly modifying a feature. Internally, geogit-py still calls GeoGit import/export commands but wraps them to expose them in a more practical way. It is also more efficient, since it does not import/export the whole layer. Here’s an example.

# Take a feature and modify its geometry
feature = repo.feature(geogit.HEAD, 'parks/1')
geom = feature.geom
attributes = feature.attributesnogeom
newgeom = geom.buffer(5.0)

# insert the modified geometry and create a new snapshot with the changes
repo.insertfeature(feature.path, attributes, newgeom)
repo.addandcommit('modified parks/1 (buffer computed)')

In this case we have computed a buffer, but you can modify the geometry as you like. Geometries are Shapely objects, so you can use all the methods in that powerful library to work with them. You can also modify the non-geometry attributes in the feature (though we haven’t done so in that example).

Working with GeoGit Branches

Working with branches is also rather simple:

# Create a branch at the current HEAD commit to work on it
repo.createbranch(repo.head, 'mybranch', checkout = True)

# [...] Perform some work on the branch, modifying the repo data and creating new commits

# Bring changes to master branch (which might itself have changes)
repo.checkout(geogit.MASTER)
try:
        repo.merge('mybranch')
        print 'Merge correctly executed. No merge conflicts'
except GeoGitConflictException, e:
        print 'Cannot merge. There are merge conflicts'

Growing GeoGit

Although most of the functionality of GeoGit is already available through geogit-py, some features are not yet supported. Unsupported features mostly correspond to convenience options that can very easily be implemented, or replicated with a few lines of Python code.

A side effect of developing geogit-py is that it has helped us improve GeoGit itself. Several new features have been added to GeoGit commands to allow for a better integration, and some new commands have even been implemented. Using GeoGit from geogit-py has given us more insight into ways that GeoGit can be used by different applications and services, and has helped us shaping it and improving it.

A comprehensive test suite is included with geogit-py, which represents a real test suite for GeoGit itself, adding to the large collection of sets that GeoGit has. Moreover, we have plans to use geogit-py as part of our quality assurance, specifically for testing GeoGit and prototyping GeoGit use cases.

Soon we will release some of the projects that we are working on that rely on geogit-py. Stay tuned for further updates.

The post GeoGit for Python: Announcing geogit-py appeared first on Boundless.

by Victor Olaya at April 02, 2014 01:55 PM

EasySDI Community

Steering Committee

The steering committee meets once a month to perform strategic choices.

Steering committee is composed from:

-> Bruno Magoni (DEPTH SA)

-> Xavier Merour (ASIT VD)

-> Laurent Plainecassagne (DEPTH FRANCE)

-> Jerôme Teixeira (Syndicat Informatique de Charente Maritime)

by Laurent Plainecassagne (plainecassagne@depth.fr) at April 02, 2014 12:58 PM

EasySDI Community

Community organisation

1. Overview

The Community consists of all users of the EasySDI solution. Users are independant and their participation in the project is voluntary based. Each user is free to use EasySDI code in respect to its GPL V3.0 licence.

Within the EasySDI project the following kinds of roles are recognized:

-> Users download, install and use EasySDI components where Users typically contribute to documentation or configuration

-> Developers are people able to apply changes to the EasySDI source code

-> Committers are allowed to commit artefacts to the EasySDI code repository

The Project Steering Committee is a small group of individuals who are responsible for all organisational and strategic aspects of project management

 

The remainder of this document contains more detailed information about these groups or structural entities.

 

2. Community detailed description

 

Users

Users are individuals or institutions who download, install and use EasySDI components. They can contribute to the Community with forums posts, tutorialsand documentation writing, funding work, etc.

Developpers

Developpers are individuals or institutions who are able to apply changes to the EasySDI source code and submit patches .

Committers

Committers are individuals from the Developers groups who are allowed to commit artefacts to the EasySDI code repository.

Commit rights are granted upon request by the PSC. Individuals who already have contributed significant resources to the project may apply for commit rights. The prior commitment is usually shown by regularly submitting code that conforms to the current é EasySDI development best practices é and by involvement into the discussions at the developer and user list.

Project Steering Committee (PSC)

The Project Steering Committee is a small group of individuals who are responsible for all organisational and strategic aspects of project management.

PSC consists of individuals recognized for their competences or dynamism within the Community. The PSC decides about the major directions of the EasySDI project, the roadmap and the Committers. All decisions made by the PSC are either made in consensus or based on a single majority. The PSC usually meets online once a month and physically once a year in person.

Responsibilities of the PSC include:

-> setting the overall development road map

-> ensuring regular releases (major and maintenance) of EasySDI solution

-> overall technical aspects and strategic choices of EasySDI solution

-> project infrastructure (e.g. SVN, Mailing Lists, Wiki, Tracker, hosting options, etc...)

-> formalization of affiliation with external entities

-> setting project priorities, especially with respect to project sponsorship

-> creation and oversight of specialized sub-committees (e.g. project infrastructure, training)

-> vote on PSC membership

by Laurent Plainecassagne (plainecassagne@depth.fr) at April 02, 2014 12:31 PM

EasySDI Community

Join us !

EasySDI is an open source project : you can contribute to its evolution.

ask for support

report bugs and propose evolution

participate to forums and watch news

download source code

write documentations & tutorials

 

http://forge.easysdi.org

 

Feel free to contact any member of the steering committee for any contribution proposal.

 

 

Community of Practice


Beyond the technical solution, EasySDI seeks to bring together a community of actors sharing a common professional practice: the sharing of geographic data. The project aims to promote knowledge and best practices sharing in the field of spatial data infrastructure through collective capitalization and pool of expertise.

By joining the community of practice, you will participate in improving the collective intelligence around the project and enhance your own approach!

by Laurent Plainecassagne (plainecassagne@depth.fr) at April 02, 2014 12:05 PM

gvSIG Team

Programa Jornadas gvSIG de Latinoamérica y Caribe

0_LACYa hemos reseñado en varias ocasiones el carácter especial (y espacial!) que tienen las Jornadas gvSIG de Latinoamérica y Caribe de este año, que junto a MundoGEO#Connect constituyen un punto de encuentro casi obligatorio de la comunidad geo de América Latina.

Desde hace unos días está disponible el programa de estas jornadas, en el que podemos encontrar un amplio conjunto de ponencias de variedad temática y geográfica que son representativos de la diversidad de áreas en las que gvSIG se aplica hoy día, desde el sector petrolero a la criminología pasando por la gestión municipal o de cuencas hidrográficas, ponencias en las que presentaremos las últimas novedades de la tecnología que se impulsa desde la Asociación gvSIG y los retos que nos planteamos para el futuro. Todo ello completado con 3 talleres donde los usuarios podrán aprender a manejar gvSIG y a aplicarlo a distintos usos.

Cerrando las jornadas una mesa redonda que tratará de forma clara y directa las relaciones entre soberanía tecnológica y software libre en Latinoamérica.

Pero principalmente las jornadas serán el punto de encuentro de la Comunidad gvSIG, un espacio de colaboración y solidaridad entorno al conocimiento compartido.

La inscripción a todas las actividades de las jornadas es totalmente gratuita y debes realizarla a través de la web del evento. Eso sí, el aforo es limitado y no serían las primeras jornadas donde colgamos el cartel de “Aforo completo”.


Filed under: community, events, gvSIG Desktop, i3Geo, spanish

by Alvaro at April 02, 2014 07:27 AM

April 01, 2014

gvSIG Team

Are you ready?

Itscoming


Filed under: gvSIG Desktop, press office

by Alvaro at April 01, 2014 02:16 PM

Boundless Blog

Code Sprinting in Vienna

Over 50 people came together in Vienna last week for five days of working on open source geospatial software. This code sprint merged the annual “C tribe” sprint — PostGIS, MapServer, GDAL, PDAL, and others — with the regular sprints held by the QGIS and GRASS communities. As a result, the attendance was at a record level, and the opportunities for collaboration much greater.

PostGIS 2.1.2 & 2.0.5 Released

I attended to work on PostGIS development, as usual, and achieved my modest goal: closing all the remaining tickets and getting 2.1.2 and 2.0.5 released. These are both bug fix releases, so no new functionality is included, but there are some important issues in the 2.1 branch that were resolved with the 2.1.2 release.

More QGIS in Our Future

Wearing my OpenGeo Suite product manager hat, the sprint was an excellent opportunity to sit down and talk with leaders in the QGIS community about our plans for bundling QGIS with OpenGeo Suite. When OpenGeo Suite 4.1 is released later this year, it will include builds of QGIS for all our supported platforms (Windows, OSX, Linux). It will also have some specialized plugins for managing map composition and versioned editing within QGIS. Our own Victor Olaya is a QGIS community member and a developer of the the Processing framework (formerly Sextante) in QGIS. We’re looking forward to being a part of the QGIS community, in the same way that we are a part of the OpenLayers, GeoServer and PostGIS communities.

Building Community

Five days is a long time to hunker down in a room slinging a code, and there were a lot of valuable side meetings: developers showed off some of their latest work (I saw some great 3D work from the PDAL’s Howard Butler and Oslandia’s Olivier Courtin); the QGIS community worked through important design decisions; and Tim Sutton and Anita Graser collected lots of interviews for the QGIS podcast.

Code Sprint Beer Mat

The “beer track” (not run concurrently with the other tracks) was also great, thanks to Stephan Meißl’s organizing: some onsite events, a walk and dinner in downtown Vienna, and a dinner in the local neighborhood. Most importantly, opportunities to get to know developers from other communities and bring the whole open source geo community closer together.

Next year, the sprint will once again combine as many communities as possible (hopefully adding some!), this time in a North American venue (likely Philadelphia). I’ll certainly be in attendance. If you write open source geo software, I hope you will too.

 

The post Code Sprinting in Vienna appeared first on Boundless.

by Paul Ramsey at April 01, 2014 01:44 PM

Jackie Ng

GeoREST as re-imagined by mapguide-rest: Part 2 - The XML adapter

For this post, we are going to talk about one of the adapters provided by mapguide-rest: The XML adapter.

This won't be a comprehensive guide, you can consult the adapter documentation in the github wiki for all the gritty details. This will just be a basic overview of the adapter

The XML adapter lets you provide an XML representation of feature data from any MapGuide Feature Source. The name of this adapter is FeatureSetXml. When reading XML via this adapter (using HTTP GET), the XML is the same format as the XML data returned by a SELECTFEATURES operation from the mapagent.

While the value of consuming MapGuide feature data in this format may be debatable, what the XML adapter special and where it is most valuable is that it is the only adapter to support CRUD through the quartet of HTTP verbs:
  • GET: For reading one or more features
  • POST: For inserting one or more features
  • PUT: For updating one or more features
  • DELETE: For deleting one or more features
All other adapters only provide GET support (to "read" feature data as a particular format). This is the only adapter to support feature manipulation.

Configuration

To enable XML representation support for your feature source, your restcfg.json should look like this:

{
"Source": {
"Type": "MapGuide",
"FeatureSource": "Library://Samples/Sheboygan/Data/Parcels.FeatureSource",
"FeatureClass": "SHP_Schema:Parcels"
},
"Representations": {
"xml": {
"Adapter": "FeatureSetXml",
"Methods": {
"GET": {
"MaxCount": 500
},
"POST": {},
"PUT": {},
"DELETE": {}
}
}
}
}

The above configuration will enable support for all 4 HTTP methods. If you do not want to support a particular method on this Feature Source, then simply remove the corresponding method key from the Methods section of the above configuration. Attempts to make requests to this data source using such un-configured methods will return HTTP 405 (method not allowed).

Reading XML Features

Assume the above restcfg.json resides in /conf/data/property/restcfg.json

To get the XML of this data source is simply to issue a GET request like this:

GET http://servername/mapguide/rest/data/property/.xml


The number of features in this result will be capped at 500 due to the MaxCount property in the configuration.

You can also request the XML of a single feature by putting the actual ID value of the feature into the URL like so

GET http://servername/mapguide/rest/data/property/45.xml


Inserting XML Features

Assume the above restcfg.json resides in /conf/data/property/restcfg.json

Inserting a new feature requires a HTTP POST to the multiple results URL. Your XML body should be structured as follows:

  • A top-level FeatureSet element
  • With a Features element
  • With a Feature element for each feature you want to insert.
  • Each Feature element should have one or more Property elements
  • Each Property element should have a Name element containing the property name and a Value element containing the property value. Geometry values must be in WKT format

A successful request will return an XML envelope containing the ID values for the inserted feature.



Updating XML Features

There are 2 ways to update features.

  • A PUT request to the multiple results URL
  • A PUT request to the single result URL
Your XML request body must be structured as follows
  • A top-level UpdateOperation element
  • With a Filter element which is the FDO filter for features to be updated. If issuing a PUT request to a single results URL, this element is not required as the filter can be inferred from the URL itself.
  • Also with a UpdateProperties element
  • Containing one or more Property elements
  • Each Property element should have a Name element containing the property name and a Value element containing the property value. Geometry values must be in WKT format. Null values can be specified by omitting the Value element.
Note that on IIS, PUT requests is probably not allowed by default, so you'll probably have to use a POST request and include a X-HTTP-Method-Override = PUT request header.

Sending the request will return an XML envelope indicating the number of features updated by this request.


Deleting Features

Like updating, there are 2 ways to delete features
  • A DELETE request to the multiple results URL
  • A DELETE request to the single result URL
No XML request body is required. You just have to specify a filter parameter that indicates what features will be deleted. If the request is to a single result URL, this parameter is not required as the filter will be inferred from the URL itself.

Like PUT, DELETE is probably not allowed on IIS by default, so you can work around that by using a POST request and include a X-HTTP-Method-Override = DELETE request header.

Sending the request will return an XML envelope indicating the number of features deleted by this request


Transaction Support

For providers that support it, you can configure such CRUD operations to use transactions by specifying UseTransaction: true in the relevant methods in restcfg.json

{
...
"Representations": {
"xml": {
"Adapter": "FeatureSetXml",
"Methods": {
"GET": {
"MaxCount": 500
},
"POST": {
                    "UseTransaction": true
                },
"PUT": {
                    "UseTransaction": true
}, "DELETE": {
                    "UseTransaction": true
                }
} } } }

In Summary

The XML adapter is useful for doing CRUD operations using standard HTTP requests and the specially crafted XML request envelopes as described in this post. No special code or APIs required!

by Jackie Ng (noreply@blogger.com) at April 01, 2014 11:28 AM

Jackie Ng

GeoREST as re-imagined by mapguide-rest: Part 1

So after a little tour of the REST API, we now come to the other half of mapguide-rest: The re-imagined GeoREST-style data publishing framework.

If you have used GeoREST before, most of what I will be showing here should be familiar to you conceptually.

Introduction

If you've never used GeoREST before, it is a framework for publishing spatial data (from a MapGuide Feature Source or a raw FDO connection) in one or more various formats and representations, such as:
  • GeoJSON
  • XML
  • OData
  • PNG
  • HTML (via templates)
  • KML (via templates)
  • GeoRSS (via templates)
  • CSV (via templates)
Published spatial data sources follow RESTful principles for interaction and data access.
  • Clients use HTTP GET to "read" features from the data source
  • Clients use HTTP POST to "create" features in the data source
  • Clients use HTTP PUT to "update" features in the data source
  • Clients use HTTP DELETE to "delete" features in the data source
GeoREST enables CRUD for certain Feature Sources without needing to know specifics of the MapGuide API. Accessing this data does not require the use any specialized client libraries and APIs or knowledge of SOAP or other specialized RPC mechanisms. Only knowledge of how to make HTTP requests is required. Based on the type of representation and what's configured for the data source, certain operations may or may not be supported.

The other major feature is that access to such data will generally have clean URLs which assists in bookmark-ability and makes such published data easy to access by humans and machines alike.

While GeoREST offers something unique, for mapguide-rest I wanted to go back to the drawing board on this idea for reasons already stated.

Differences from GeoREST

The main differences in mapguide-rest that distinguish it from GeoREST are:
  • Configuration is done by JSON files instead of XML files
  • Because mapguide-rest is in PHP, it also works in Linux versions of MapGuide/AIMS where GeoREST is windows-only.
  • mapguide-rest is not tied to a specific version of MapGuide/AIMS and can work on any version of MapGuide/AIMS that bundles PHP 5.3 or newer (though we recommend using it on the latest releases).
  • Also because of PHP, mapguide-rest uses the more powerful and flexible Smarty template engine for any template-based representations instead of GeoREST's ctemplate engine allowing for more expressive content templates.
  • The base URL where data sources in mapguide-rest can be accessed is strictly based on the relative location of its configuration file and not based on the value of uripart in restcfg.xml for GeoREST.
  • mapguide-rest provides an easy API to extend it with your own custom formats/representations or geometry/datetime formatters for templated content.
  • mapguide-rest provides coordinate transformation capabilities out of the box.
  • mapguide-rest in its current iteration is yet to support OData like GeoREST currently does.
  • mapguide-rest does not support raw FDO connections as a data source. Only MapGuide Feature Sources are supported.
Configuration

Configuration files are JSON-based and reside under the /conf/data subdirectory of your mapguide-rest installation. These files can reside any levels deep within this folder. These configuration files are named restcfg.json and its relative location determines the base URL in which to access that particular configured data source.

Here's a basic example restcfg.json

{
"Source": {
"Type": "MapGuide",
"FeatureSource": "Library://Samples/Sheboygan/Data/Parcels.FeatureSource",
"FeatureClass": "SHP_Schema:Parcels"
},
"Representations": {
"xml": {
"Adapter": "FeatureSetXml",
"Methods": {
"GET": {
"PageSize": 100,
"MaxCount": 500
}
}
},
"html": {
"Adapter": "Template",
"Methods": {
"GET": {
"PageSize": 100,
"MaxCount": 500,
"MimeType": "text/html",
"Templates": {
"Single": "property_html_single.tpl",
"Many": "property_html_many.tpl",
"None": "property_html_none.tpl",
"Error": "property_html_error.tpl"
}
}
}
}
}
}

As you can see, the structure of restcfg.json is easy to follow:
  • There is a top-level Source property that indicates the MapGuide Feature Source that we want to make available for RESTful access
  • There is a top-level Representations property that contains one or more supported data formats that specifies the Adapter that will handle this particular representation along with adapter-specific configuration options for each HTTP method that you want to allow through that particular representation (and is supported by the given adapter)
The above restcfg.json enables the Parcels Feature Source to be accessible:
  • As XML data
  • As a set of web pages with master-detail type of navigation
URL Conventions

All URLs follow the following forms:
  • Multiple results: http://servername/mapguide/rest/data/[RELATIVEURIPART]/.[FORMAT]
  • Single results: http://servername/mapguide/rest/data/[RELATIVEURIPART]/[FEATUREID].[FORMAT]
As mentioned above, the location of restcfg.json will determine the base URL which to access data from this particular data source. The RELATIVEURIPART of the above URLs is based on the relative path of this restcfg.json file.

For example, if restcfg.json was stored like so

 - REST_INSTALL_DIR
- conf
- data
- sheboygan
- property
- restcfg.json

Then the URL for accessing the detail page of a specific parcel would be:

http://servername/mapguide/rest/data/sheboygan/property/1.html

The FORMAT of the above URL is the name of the extension keyed under the Representations part of restcfg.json and will let mapguide-rest determine which adapter to instantiate to handle this particular request.

For individual feature access, specifying the value of [FEATUREID] will cause the designated adapter to only return the matching feature whose identity property value is [FEATUREID] in the adapter's given format/representation.

All adapters will be processing URLs in these two forms.

Adapters

Adapters are classes in mapguide-rest which will be instantiated based on the given extension in the incoming URL and will be used to handle the particular HTTP request. Adapters will perform specific actions based on the request URL and the particular HTTP method used.

For example, for the FeatureSetXml adapter:

  • A HTTP GET will return one or more features from the Feature Source in XML format
  • A HTTP POST will insert one or more features into the given Feature Source based on the XML content in the request body
  • A HTTP PUT will update one or more features in the given Feature Source based on the filter and properties specified in the XML request body
  • A HTTP DELETE will delete one or more features in the given Feature Source based on the filter specified in the request parameters
Other adapters may only support certain methods (for the record, only FeatureSetXml supports GET/POST/PUT/DELETE. Other adapters only support GET)

mapguide-rest includes the following adapters:
  • FeatureSetXml - Outputs feature data as XML, also supports create/update/delete of features if configured
  • FeatureSetJson - Outputs feature data as GeoJSON
  • FeatureSetCsv - Outputs feature data as a CSV file. Geometry values are written as WKT
  • MapImage - Outputs feature data as a map image with the feature(s) in question being selected
  • Template - Outputs feature data through a user-defined smarty template.
Adapters are the key to how data publishing works in mapguide-rest. I have a feeling that this could be a somewhat lengthy series of posts. So I'll stop here for now. Stay tuned as I go through each adapter in greater detail.

by Jackie Ng (noreply@blogger.com) at April 01, 2014 10:54 AM