Planet Georezo » Planet OSGeo

Un Planet est un site Web dynamique qui agrège le plus souvent sur une seule page, le contenu de notes, d'articles ou de billets publiés sur des blogs ou sites Web afin d'accentuer leur visibilité et de faire ressortir des contenus pertinents aux multiples formats (texte, audio, vidéo, Podcast). C'est un agrégateur de flux RSS. Il s'apparente à un portail web.
Vous pouvez lire le billet sur le blog La Minute pour plus d'informations sur les RSS !

Feeds

61196 items (0 unread) in 112 feeds

Dans la presse

Du côté des éditeurs

Toile géomatique francophone

Géomatique anglophone

Blogs GeoRezo.net

Autres planets

Planet OSGeo

Abonnez vous à cette page (RSS) !

Planet OSGeo

Skip to page: 1 2 3 ... 53

24 mai 2013
9:44
gvSIG Team: gvSIG 2.0: Teselas de OpenStreetMap
sur Planet OSGeo

La versión 2.0 de gvSIG mejora el acceso ráster incorporando la posibilidad de teselar las fuentes de este tipo de dato, locales o remotas. El resultado es que las capas ráster se cargan sobre la vista de gvSIG en forma de pequeñas porciones o teselas que permite un renderizado progresivo de la capa. Las capas se dividen en niveles preestablecidos de distintas resoluciones y se generan estas teselas para cada nivel en tiempo de ejecución, es decir a medida que se van haciendo peticiones (zooms) de nuevas zonas se van generando las teselas o tiles.

Pero la mayor ventaja de este sistema es que podemos guardar en una caché todos los tiles. De esta forma, la información que se descarga desde los servidores no tiene que volver a pedirse una vez ya se ha hecho, ya que las siguientes peticiones se sirven desde los datos cacheados, con la consiguiente mejora de rendimiento.

De esta forma, la incorporación de nuevas fuentes de datos con este sistema de pirámides de resolución es fácil. Debido a esta posibilidad ha sido relativamente sencilla el desarrollo de un nuevo plugin para el acceso a las capas tileadas de servidores de OpenStreetMap, ya que, como es sabido, estos servidores sirven los datos de esta forma y es totalmente compatible con el sistema de caché incorporado en gvSIG.

Este plugin tiene un acceso básico a las capas de OpenStreetMap para visualización. Por defecto vienen configurado cuatro servidores que sirven las capas de Map Quest, Map Quest Open Aerial, Open cycle Map y Mapnik. En la propia interfaz de “Añadir capa” es posible agregar nuevos servidores, por lo que no nos limita a lo que viene preconfigurado. La interfaz para hacerlo es bastante intuitiva y requiere poca explicación. En mi opinión, este es un ejemplo de como, con poco esfuerzo se pueden aprovechar las posibilidades que de base ofrece gvSIG 2.0 para desarrollar funcionalidad.

Un problema que se presenta gvSIG con las capas de tiles de OSM es la proyección. Estas se sirven en EPSG:3785 y lamentablemente gvSIG no trae configurado de base esta proyección. Es posible crearla manualmente teniendo la cadena WKT, pero resulta algo engorroso. En este caso el plugin lo hará por nosotros. Cada vez que se arranca comprobará si existe este EPSG en la base de datos de gvSIG y si no está la creará como proyección de usuario. De esta forma ya podremos poner la vista en esta proyección para cargar la cartografía.

Otro inconveniente que podemos encontrarnos es que una vez la información está en la caché no se actualiza y si la información cambia en el servidor nosotros seguiremos cargando datos antiguos. Esto no es un problema para capas locales pero para capas remotas, como es el caso de OSM, pues si lo es. Esperemos poder disponer de mejoras que solucionen este problema.

Filed under: gvSIG Desktop, spanish Tagged: gvSIG 2.0
23 mai 2013
15:00
Slashgeo (FOSS Articles): gvSIG 2.0 Novelties
sur Planet OSGeo
During the last weeks several posts about the gvSIG Desktop novelties have been published at the gvSIG Blog. With them we try to make known all these novelties with more details. Until now, the posts that have been publisher are:
- Scripting, exploit your gvSIG (III): Generate a polygon from a course
- Symbols library “OSM”
- “Google” symbols library
- Scripting, exploit your gvSIG (II). Creating a buffer
- Mirrors for downloads
- Add-ons manager
- How to create symbol libraries (II)
- Raster data tile cache and WMTS
- gvSIG 2.0 on 64 bits or Java 1.7 systems
- Additional feature for managing CRS
- gvSIG 2.0: Scripting, exploit your gvSIG
- How to create symbol libraries (I)
In the last weeks new posts will be published, as well as the translation of the last ones in Spanish. Some of them will be related to the new add-ons that will be available for this version. They will be able to be installed from the Add-ons Manager.

Google Plus One
12:51
Jackie Ng: An elegant MgMap hack
sur Planet OSGeo
Ever wanted to set any of the following properties of a MgMap in your application code, but bemoan the fact that all these properties are read-only in the MgMap class?
- DPI
- Display Width
- Display Height
- View Center
- View Scale
Here's a neat little hack you can do
If you remember, I">[http-handler_30.html">I] previously showed how you can actually replicate mapagent functionality through the M [HttpRequest] and M [HttpResponse] classes. Armed with this knowledge, the key to changing any of the above properties is to set up the appropriate operation and parameters for an API that's only available in the mapagent: GETDYNAMICMAPOVERLAYIMAGE
GETDYNAMICMAPOVERLAYIMAGE differs from what's in the official API (MgRenderingService::RenderDynamicOverlay()) in that the mapagent version supports these additional parameters:
- SETVIEWCENTERX
- SETVIEWCENTERY
- SETVIEWSCALE
- SETDISPLAYDPI
- SETDISPLAYWIDTH
- SETDISPLAYHEIGHT
- SHOWLAYERS
- HIDELAYERS
- SHOWGROUPS
- HIDEGROUPS
These parameters actually modify the state of the MgMap that is to be rendered. Through the use of M [HttpRequest] and M [HttpResponse] we can indirectly tap into this mapagent API to achieve the same result.
Now the operation itself returns a rendered image obviously, so if we want this to be snappy (as we just want to modify MgMap state and don't really care about the rendered result), you'd want to request something that requires very minimal processing overhead to produce the rendered image. So under these conditions, the ideal parameters to supply to GETDYNAMICMAPOVERLAYIMAGE are:
- BEHAVIOR = 1 (Selected features only)
- FORMAT=PNG8/JPG (Smallest image format in case we actually do have a rendered selection)
I've attached a PHP code sample that demonstrates this technique.
9:01
gvSIG Team: gvSIG 2.0: Data in NetCDF
sur Planet OSGeo

NetCDF is a data format oriented to scientific data in a multidimensional arrays way. That is, a list of variables with a concrete meaning (pressure, temperature, position…). It’s commonly said that it’s a data container of any type and auto-descriptive. It means that its contents is described in its header.

As generic container it has the advantage of storing raster as well as vector data, and they can be specified for different moments over time. It’s useful for storing on site data that are obtained from sensors where the information collection is periodic and the collected data are varied.

Two plugins have been developed for gvSIG 2.0, that offer support for NetCDF. Its integration in gvSIG has been made from the point of view of the same application, separating the support in two different data providers: raster and vector. It’s because its graphical representation in gvSIG is totally different. With the incorporation of this format, gvSIG can load and export data with time information.

But the time information requires a special treatment in any Geographic Information System, now that the user should be able to filter the information to be shown in a specific moment or in a temporary interval. Besides the user should be able to process the data taking the moment into account or even to be able to make animations throughout time. In this sense gvSIG has improved in an important way, because it incorporates this functionality (data filter by time and short animations). At this moment this tool has to be improved to make geoprocessing on layers with time information, besides integrating time support on the raster part. We hope to improve this issues in the future versions, although these plugins are available now.

Filed under: gvSIG Desktop, opinion, spanish
6:03
GIS Professionals in Iran: ‫حالت های مختلف کار با MapServer‬
sur Planet OSGeo
Mapserver در دو حالت مختلف می تواند عمل نماید : CGI Script MapScript حالت CGI Script در حالت اول توابع آن در محیط وب همانند یک CGI Script عمل می کنند، بنابراین حالتی آسان برای تنظیم و کاربرد روان و کاربرپسند دارد.در اغلب موارد Map server یک برنامه ی CGI بوده که به صورت غیرفعال [...]
نوشته حالت های مختلف کار با MapServer اولین بار در سایت تخصصی جی.آی.اس پدیدار شد.
پست های مرتبط:
22 mai 2013
18:02
OpenGeo Blog: Announcing Mapmeter: a new tool for analyzing geospatial deployments
sur Planet OSGeo

This week at FOSS4G-North America 2013 in Minneapolis, we are excited to announce a full public beta of our new product. What we’ve previously referred to as “The Enterprise Console,” is now Mapmeter, a full administration and management tool for analyzing GeoServer systems.

Mapmeter enables organizations to monitor the health of production deployments, optimize applications during development and diagnose critical issues. With these details, administrators and managers can better — and more cost effectively — make decisions about their geospatial deployments. With Mapmeter, spatial monitoring and reporting become a primary component in your spatial IT workflow.

You may have heard us talk about this product in recent months. We started with an announcement at FedGeo, then Alyssa Wright showed a live demo with James Fee, and some of you were able to get in on a private beta. With the help and feedback of our early testers, we are now able to open up the software to all.

If you want to learn more or see a demo, please join us for the Mapmeter launch at Sponsor Day at FOSS4G-North America at 9 a.m. Friday, May 24 (look for the OpenGeo room). Sponsor Day is free, but you need to register. We’ll also be holding office hours at our FOSS4G North America booth today (5/22/2013) from 2:00pm to 3:00pm.

If you won’t be able to join us in Minneapolis, head over to [mapmeter.com] to learn more about these exciting new features, connect with the development team and join us for this beta program.

We hope you’re as excited as we are about Mapmeter! If you have questions, please contact us. You can also contact the Mapmeter team directly for personalized help with the public beta.
15:22
Simone Giannecchini
sur Planet OSGeo
GeoSolutions is looking for talented people to fill a couple of positions which would mainly involve designing, implementing testing web-based geospatial applications as well as providing support for the Open Source projects we are involved in.

Here below some additional details:

Support Engineer
This position will mainly focus on having our clients receive the support they need in time and with the quality level they expect from us. The ability to work and communicate clearly in a fast-paced environment is essential since the Support Engineer will be the main point of contact between clients and developers and as such he will be responsible for mediating and coordinating clients' needs. Customers' satisfaction is going to be your mission!

Main Responsibilities are as follows:
- Create documentation and trainings
- Play the Q&A Engineer role when needed
- Monitor quality and SLA levels for support accounts. Manage and improve support procedures as needed
- Coordinate with development team to get updates on ongoing as well as planned planned enhancements for the products
- Interface with development and support teams from GeoSolutions as well as customers to ensure resolution of all customer calls
- Periodically report status and strategic recommendations from clients to GeoSolutions leadership
Qualifications are as follows:
- 1 year in technical support management, including personnel management
- Familiarity with CRM or issue management systems
- Working knowledge of GeoServer
- Good Knowledge of most important OGC specifications and concepts (WMS, WFS, WCS, coverage, etc...)
- Working knowledge of OpenLayers is a plus
- Working knowledge of GeoNetwork is a plus
Front End Developer
This position would mainly involve designing and implementing web-based geospatial applications as well as providing support for the Open Source projects we develop.
Qualifications are as follows:
- Working knowledge of OpenLayers and GeoExt
- Working knowledge of frameworks like JQuery, Ext-JS
- Working knowledge of HTML5 and development of mapping webapp for the mobile world
- Working knowledge of frameworks like LeafLet, Recline-JS is a plus
- Knowledge of web development with Python is a plus
- Knowledge of Java (JEE and JSE) is desirable but not necessary
- Knowledge of GeoServer is desirable but not necessary
- At least 1 year of experience
- Being fluent in English, both written and spoken
What we offerWe can offer a variety of contracts but, please, notice that our intention is to establish a long term relationship, although as a temporary solution we do accept freelance consultants.Working remotely is an option we envisage, although we will give priority to candidate closer to our office.

Please send a detailed resume together with a letter of presentation at jobs_at_geo-solutions.it.

The GeoSolutions team,
14:41
Andreas Schmitz: Hans Moleman issues
sur Planet OSGeo

XML, especially GML schema validation can be hard. The mysterious Xerces 'honor all schema locations' flag springs to mind (this is a mystery yet to be fully understood). Often, slow schema validation processes (which seem to fetch schemas from the web) can be traced to Hans Moleman. No, sorry, wrong link, to Hans Moleman.

So what's happening? And what does Hans Moleman have to do with it?

As the GML experts among you may know, GML application schemas depend on the GML schema, which in turn consists of many (varies amongst versions) schemas, depending on other schemas like for example the W3C XLinks schema, which in turn includes the W3C XML schema (the schema for the xml namespace itself: [www.w3.org]

So even when validating a feature collection against a local version of a GML application schema, the schema parser might still get to a point where it needs to fetch dependent schemas from the internet. And since the xml.xsd is the last one in the chain, it's also the one that gets requested the most.

According to W3C people, they had ~130 million accesses to this file per day, and since decided to completely block eg. the Java default HTTP UserAgent and others. Apparently they later had a change of heart, and don't block it any more, but the xml.xsd URL has a delay of several seconds upon loading (see [www.w3.org] ).

So when validating multiple documents, which all need the xml.xsd, with all schemas loaded freshly every time, you'll get a delay of several seconds where your computer seems to do nothing at all.

We've thought about the problem of remote schemas quite a while ago, and made use of a custom Xerces entity resolver to load OGC and W3C schemas from a local artifact which we ship with deegree. There would also be other solutions, our JAXB schema generation for example makes use of standard XML catalog files to avoid fetching schemas from the web.

But unfortunately the CITE WFS 1.0.0 tests (and others) do not (although newer versions tend to load required schemas from the classpath as well).

Using reverse engineering using an eclipse plugin (see the other post from today) I was able to fix this (they were already using a custom entity resolver, loading everything from the web all the time). Now a complete deegree build including integration tests runs only needs 13 minutes on fast machine!

For those interested, have a look at our deegree-compliance-tests module.
12:30
Andreas Schmitz: All the library sources
sur Planet OSGeo

One of the nicer features in eclipse is that it is able to automatically browse not only through your own sources, but through library sources as well, if they're available. But what if they're not?

In that case eclipse shows the class in a byte code view, with a button to attach a source .jar. Unfortunately it is often the case that you don't have the sources, either because they were not uploaded to maven central, or because they're closed altogether.

In any case, it is obviously often desirable while debugging to see what a library function actually expects, or why it fails. Contrary to popular belief, the actual code is always the ultimate documentation, because it's up to date even if human language docs are not.

So recently, while chasing after a Hans Moleman issue (more on that later), I needed sources from binary classes. Of course my first thought was 'decompiler', so I searched the eclipse marketplace for 'decompiler'.

I found JadClipse for eclipse 4.x, installed it, and voila: when I double click on a class file with no sources attached, the decompiler automatically decompiles it and shows me the source. Now that's what I call a plugin without hassle! That's a perfect counterpart to the -DdownloadSources flag for the maven eclipse mojo, now I never need to go without a library source again.
7:56
gvSIG Team: gvSIG 2.0: Biblioteca de símbolos “Emergency”
sur Planet OSGeo

Uno de los ámbitos en los que gvSIG se está utilizando cada vez más es en el de gestión de emergencias, tanto a nivel urbano como de catástrofes naturales. Sin duda, es más que significativo el aporte que el análisis espacial puede suponer para la gestión de emergencias y campos relacionados como el análisis delictual.

Orientada a estos usuarios hemos realizado una nueva biblioteca de símbolos. Como es habitual disponible desde el “Administrador d e complementos”.

Para los símbolos puntuales (marcadores) hemos partido de un conjunto de símbolos denominado “EMS.The Emergency Mapping Symbology”, realizado por el Departamento de Recursos Naturales de Canadá que tal y como indican es de libre uso. La forma de importarlos ha sido la habitual, descrita en este post.

Como en casos anteriores hemos utilizado pyRenamer -una herramienta de renombrado masivo de archivos-, ya que el nombre que gvSIG da a cada símbolo es el nombre del fichero. El objetivo del renombrado es facilitar la identificación de símbolos.Estos símbolos están diseñados para utilizarse con un tamaño de 32 píxeles -con el objetivo de resaltar su importancia en el mapa- por lo que los hemos importado a ese tamaño. Reduciéndolo a tamaños inferiores también se visualizan correctamente.

Mediante GIMP hemos generado los distintos símbolos de selección. En este caso, al haber símbolos con tonalidades de amarillo, hemos decidido que los símbolos de selección se representen en escala de grises. Con la opción de GIMP Imagen/Modo/Escala de grises hemos convertido los símbolos a escala de grises, añadiendo “_sel” al nombre del fichero para que gvSIG lo interprete automáticamente como símbolo de selección.

Además de símbolos puntuales, queríamos que esta biblioteca contuviera un conjunto de símbolos de líneas y relleno útiles para los mapas de emergencias, delitos,etc.

Hemos generado tanto símbolos lineales:Como símbolos de relleno, inspirados en el documento Biosecurity Emergency Management – Mapping Symbology:Ya sólo nos queda crear el paquete tal y como explicamos en este p ost.

Este paquete lo tenéis disponible desde el administrador de complementos (seleccionando la URL http://downloads.gvsig.org/download/gvsig-desktop/ y buscando por “Tipos/symbols”)o directamente descargándolo desde aquí.

Filed under: gvSIG Desktop, spanish Tagged: gvSIG 2.0
1:40
Cameron Shorter: Will OGC’s standards meet government purchasing guidelines?
sur Planet OSGeo
In what has become the OGC’s most contentious vote to date, OGC members are being asked whether the proposed "Geoservices REST API" should be accepted as an OGC standard. A summary of concerns are listed in an Open Letter from the Open Source Geospatial Foundation (OSGeo) to the OGC. However, the crux of contentions hinge around the definition of an Open Standard and whether the "Geoservices REST API" qualifies as one.
When measured against government’s policy drivers of interoperability, fair competition, and economical use of government funds, the evidence is overwhelming. "Geoservices REST API" fails on all accounts. In fact, we should be questioning why our OGC processes haven’t identified and then addressed these issues much earlier.
Background
As background, the "Geoservices REST API" describes the interface to a dominant vendor’s web service (ESRI’s ArcGIS Server), and overlaps substantially with OGC’s existing suite of web service standards.
What is an Open Standard?
Most government purchasing guidelines, such as the United Kingdom Open Source, Open Standards and ReUse: Government Action Plan, now include clauses such as:
The Government will use open standards in its procurement specifications and require solutions to comply with open standards. The Government will support the development of open standards and specifications.
Consequently, government contracts typically specify OGC standards when purchasing spatial systems. This places a responsibility on the OGC and OGC members to protect government policy when selecting and defining the OGC standards baseline.
Superficially, the "Geoservices REST API" meets the European Interoperability Framework minimal definition of a standard:
- The standard is adopted and will be maintained by a not-for-profit organisation, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties (consensus or majority decision etc.).
- The standard has been published and the standard specification document is available either freely or at a nominal charge. It must be permissible to all to copy, distribute and use it for no fee or at a nominal fee.
- The intellectual property - i.e. patents possibly present - of (parts of) the standard is made irrevocably available on a royalty-free basis.
- There are no constraints on the re-use of the standard.
However, the "Geoservices REST API" falls short of addressing government policy drivers for the creation of standards. These are summarised in the Guideline on Public Procurement of Open Source Software, written for the European Commission:
Public sector consumers of software have an obligation to support interoperability, transparency and flexibility, as well as economical use of public funds. When it comes to public procurement, the principles applied to the public sector require them to support (and certainly not to harm) competition through their procurement practices. ...
Good practice eGovernment services should provide access based on open standards, and in particular, never require citizens to purchase or use systems from specific vendors in order to access public services: this is equivalent to granting such vendors a state-sanctioned monopoly.
Lets address these issues point by point.
Costs and Interoperability
Regarding when to create new standards, the United States Open Technology Development (OTD): Lessons Learned & Best Practices for Military Software has the following advice:
... use/modify/create open standards, in that order.
Unfortunately, the "Geoservices REST API" would create new standards rather than use and/or extend existing OGC web services. Emphasis on reuse of standards is important for increasing interoperability, as duplication of standards typically results in:
1. Implementation costs to support multiple standards increases.
2. Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
3. Sponsors (such as governments) who require compliance with standards will discover that applications don't communicate together, due to applications supporting different standards that essentially do the same thing.
Costs increase, interoperability decreases.
Fair competition
ESRI’s ArcGIS Server is currently the only server which provides a full implementation of the "Geoservices REST API", as you would expect when an API is derived directly from a product. As such, if the "Geoservices REST API" were to be included in the OGC baseline, and government contracts continue to reference the OGC baseline in contracts, then governments would be giving one vendor a significant market advantage while other vendors wear the cost of developing matching implementations for the proposed standard.
Further, ESRI may continue to use its market dominance to promote use of the "Geoservices REST API" at the expense of existing OGC web services. (As described in ArcGIS Server documentation, support for OGC’s W*S services are disabled by default while GeoServices REST and KML are enabled).
Where are the Open Source implementations?
Another test for identifying open standards is defined by the United States Open Technology Development (OTD): Lessons Learned & Best Practices for Military Software:
Verify that the standards used are open; a simple test for openness is to determine if the standard is implemented by open source software.
Currently, very little open source has been developed to support the "Geoservices REST API" and there is wide opposition to the proposed standard from the Open Source community.
Open Source implementations referenced by proponents of the "Geoservices REST API" include immature implementations, partial implementations and a library application. That is: a roadmap document for GeoServer, a sandbox implementation of an Openlayers client, a 52North SOS extension to ArcGIS Server and the GDAL translation library.
By comparison, there are multiple production grade, client and server, open source implementations, which cover the full breadth of existing OGC standards, which have matured over the past decade, and there are open source reference implementations for most (all?) current OGC standards.
So by the Open Technology Development definition, The "Geoservices REST API" hasn’t yet reached the maturity of an Open Standard.
Where are OGC’s gatekeepers?
There are 481 OGC members, with close to 100 of them with voting privileges, yet regularly, less than 40% of these voting members actually vote on proposed standards. This is a concern if these members are being relied upon to uphold OGC values, and we should question why voting is so low. A key factor in low voter turnout is likely the complexity and volume of material voters need to understand in order to make an informed decision. Gatekeepers just don’t have the time to be abreast of all the issues, and current standards are hard to read. The increase in the breadth and application of OGC standards has led to a stronger need for integration of standards, architectural overviews, and clearer implementation guidelines.
Maintaining and verifying quality best addressed by defining and following development and validation processes, and OGC processes should be improved to match the complexity of the systems they represent. In particular, OGC should revisit goals and requirements for quality standards, then resource technical writers and reviewers to work against such requirements. Approving a standard is therefore simplified to verifying the process is valid and has been followed. This would require OGC sponsorship priorities changed to provide greater emphasis on quality over quantity of standards.
A blueprint for moving forward
Lets expand on the steps involved in deciding on the value of a standard:
1. Governments policies should embody government best practices. Many countries have already taken this initiative.
2. Standards organisations, should embrace such government policies.
3. A clear definition of an "open standard" is required, which addresses government policy requirements of interoperability, fair competition, free access to government services, and economical use of public funds. This should be expanded into clear guidelines to be applied by OGC Gatekeepers and standards developers. The OGC should revisit the "open standards" definition, and in particular, ensure the definition extends beyond the technical to include policy implications.
4. Suitable training should be available to OGC Gatekeepers and implementers of OGC based solutions. LISAsoft provides an Effective Software Selection course which closely aligns with such training requirements.
5. The OGC and OGC sponsors should consider realigning priorities. In particular:
- Place a greater emphasis on quality over quantity of standards. This includes: harmonising competing standards, improving quality of writing to support understandability and implementability, and extend testing to verify standards are implemented correctly.
- Provide simple and clear descriptions of standards. The OSGeo-Live project has addressed similar issues by providing a concise one page project overview, plus a ten minute quickstart, translated into 11 languages, for fifty of the best geospatial open source applications.
Summary
As the success of the OGC increases, the OGC will need to be mindful of business and policy implications associated with adopting established interfaces as standards. Specifically, accepting the currently proposed "Geoservices REST API" as a standard will have detrimental impacts on interoperability, fair competition, and economic use of public funds. Instead, the positive aspects of the "Geoservices REST API" should be harmonised and incorporated into the existing OGC baseline of standards. Also, as the breadth of technology covered by OGC standards increases, it is becoming more difficult for gatekeepers to monitor the quality of these standards and consequently it is becoming more important to focus on quality and understandability of these standards. In moving forward, the OGC membership should revisit OGC priorities, and consider placing a greater emphasis on quality over quantity.
21 mai 2013
19:10
Marco Bernasocchi: Python suport even closer
sur Planet OSGeo

anybody has a hint?
17:00
Slashgeo (FOSS Articles): Batch Geonews: Debacle over OGC and the GeoServices REST API Standard, OpenLayers vs Leaflet, More Geo from Google I/O, and much more
sur Planet OSGeo
The recent geonews in batch mode, covering a larger timespan than usual.

On the open source front:
- The OSGeo presented an Open Letter to OGC on the GeoServices REST API standard, and it's pretty well documented and informative
- Here's an interesting entry on comparing OpenLayers and Leaflet
- The schedule for FOSS4G-CEE 2013 is now known
- Sean pointed me to Tom MacWright's online GeoJSON editor
- In releases, there was GeoServer 2.3.2 released and GeoTools 9.2 Released
- Getting closer to QGIS 2.0, here's nice examples of the alpha channel in QGIS color ramps
- If you did not see the press release, OpenGeo is not non-profit anymore
On the Google front:
- The influx of Google Glass stories continues, now Facial Recognition Comes to Google Glass
- Here's Kurt's list of maps-related videos from the Google I/O 2013 conference
On the Esri front:
- ABP reminds us of Esri's Severe Weather Map, including tornadoes...
- An entry on why Esri is excited about the Android Location APIs
- Data updates, World Topographic Map updated with content for the Middle East, North Africa, and the United States
- along with other updates, including Additional DigitalGlobe and community imagery added to the World Imagery map
- Also updated, ArcGIS for Windows Phone and ArcGIS API for JavaScript v3.5 Released
In the everything-else category:
- MapBox tells us they got a huge satellite update, now cloudless and with aerial imagery, but also interesting are the OpenStreetMap updates making they way to MapBox maps in only 5 minutes
- Here's a Make article on mapping buildings with a Kinect
- Some of you might be interested by the GiT4NMD conference, Geo-information Technologies for Natural Disaster Management
- Space Daily share an article named World's major development banks look closer at Earth observation
- Here's links regarding the history of apostrophes in place names
- Via SL, an article named China's Drone Program Appears To Be Moving Into Overdrive
- Those interested in the exciting MapBox work may also want to read about vector tiles of MapBox Streets
- While CAD and GIS have come closer, they remain distinct, here's an entry named Integrating geospatial into construction: the challenge
- Geoff also shares two other interesting entries, one named Economic value of big geospatial data could reach $700 billion/yr by 2020 and the other Estimating the economic and financial impact of poor data quality
Slashdot discussed a few minor geo-related stories:
- One involving GPS named Researchers Are Developing Ad Hoc Networks For Car-To-Car Data Exchange
- Privacy stories goes on, UK's 4G Network Selling Subscriber Tracking Data To Police, Private Parties and this one Congress Demands Answers From Google Over Google Glass Privacy Concerns
- Along with new challenges to locating North itself, Global Warming Shifts the Earth's Poles
In the maps category:
- Here's The Best Geographic Visualization I’ve Seen In Ages according to VerySpatial, basically a circle centered in Asia where over half of the world's population resides
- In Paris? Apple Maps for iOS Adds 3D Flyover Coverage in Paris
- MapBox shares a Q&A of the City Guides by National Geographic mobile app
Google Plus One
10:27
gvSIG Team: gvSIG 2.0: Scripting, exploit your gvSIG (III): Generate a polygon from a course
sur Planet OSGeo
Some time ago a friend of the project, Gustavo Agüero, published a post on his blog in which he explained how gvSIG generate a polygon from a bearing (or route or course). We found a very interesting exercise and with its help we implemented a script to undertake the same steps in gvSIG 2.0. The result is explained in this post.

We want to clarify that all the merit of this exercise is to Gustavo and the errors are because of our ignorance and for not properly follow his instructions. If you see some error, please, comment it and we will correct it

We start with a bearing or course that presents the data to the following structure LINE, AZIMUT, DISTANCE, being AZIMUT the angle direction in the sense counted clockwise from the geographic north (download rumbo.jpg).

The first thing to do is to save this file to a format that would be able to read from a script, this file we have created is a csv file that we named rumbo.csv (download rumbo.csv).

Once we have our file we have to think what we need to get its content into a shapefile. Obviously we’ll need a shapefile where to save the results and we’ll need to create the features to represent the data for including them on the shapefile. To create these features we’ll need to transform the polar coordinates (azimuth, distance) in rectangular coordinates (X, Y).

Some comments on that: Gustavo in his post recommend to make a representation of the data. This was very helpful to us.

In the script we will create a LINE shapefile and another one for POLYGONS. In the LINE type, we will keep heading data, data from coordinates transformation, and the resulting coordinates. In the POLYGONS shapefile will keep an identifier of the feature and a text field.

We start from a desktop gvSIG 2.0 (in my case I’ve used is build 2060 RC1) with the latest version of the scripting extension installed (currently the number 36).

Once we open the script editor (menu bar Tools / Scripting / Scripting Composer) we create a new script and start to write our script.

The first thing we’re going to do is to create the output layers using the function createShape from the gvsig module. The syntax of this function tells us that you need a data definition for the features, a route that is the place where to store the shapefile we are acreating, the projection of the shapefile, and the type of geometry that will contain. The definition of the data will be created using the function createSchema from the same gvsig module.

The source code, including comment would be:
```
import gvsig
import geom

def main():

'''
Create a polygon layer with the following data model:
    - 'ID', Integer
    - 'OBSERVACIONES', string
    - 'GEOMETRY', Geometry

Create a line layer with the following data model:
    - "ID", Integer
    - "LINEA", string
    - "GRADOS", long
    - "MINUTOS",long
    - "DISTANCIA", double
    - "RADIAN", double
    - "X", double
    - "Y", double
    - "GEOMETRY", Geometry            
'''

#Set up the projection, it is the same for both layers
CRS="EPSG:32617"

#Create the object that represent the data model for the polygonal shapefile
schema_poligonos = gvsig.createSchema() 

#Insert the filed from the data model
schema_poligonos.append('ID','INTEGER', size=7, default=0) 
schema_poligonos.append('OBSERVACIONES','STRING', size=200, default='Sin modificar') 
schema_poligonos.append('GEOMETRY', 'GEOMETRY')

#Set up the layer path. Remember changing it!!!
ruta='/tmp/rumbo-poligonos.shp'

#Create the shapefile
shape_poligonos = gvsig.createShape(
        schema_poligonos, 
        ruta,
        CRS=CRS,
        geometryType=geom.SURFACE
    )

#Create the line shapefile

#Create the object that represent the data model for the line shapefile
schema_lineas = gvsig.createSchema() 

#Insert the field from the data model
schema_lineas.append('ID','INTEGER', size=7, default=0) 
schema_lineas.append('LINEA','STRING',size=50,default='')
schema_lineas.append('GRADOS','LONG', size=7, default=0) 
schema_lineas.append('MINUTOS','LONG', size=7, default=0)
schema_lineas.append('SEGUNDOS','LONG', size=7, default=0) 
schema_lineas.append('DISTANCIA','DOUBLE', size=20, default=0.0, precision=6) 
schema_lineas.append('RADIAN','DOUBLE', size=20, default=0.0, precision=6) 
schema_lineas.append('X','DOUBLE', size=20, default=0.0, precision=6) 
schema_lineas.append('Y','DOUBLE', size=20, default=0.0, precision=6) 
schema_lineas.append('GEOMETRY', 'GEOMETRY')

#Set up the layer path. Remember changing it!!
ruta='/tmp/rumbo-lineas.shp'

#Create the shapefile
shape_line = gvsig.createShape(
    schema_lineas, 
    ruta,
    CRS=CRS,
    geometryType=geom.MULTILINE
)
```
Ok, we already have our output layers, now we are going to see how to get the data from csv file we created. Python has a module that allows csv csv file handling very comfortable ( python csv ). The source code for reading the csv file would be:
```
import csv
import os.path

#Set up the layer path for the CSV file. Remember changing it!!!
csv_file = '/tmp/rumbo.csv'

#Check that the file exists on the provided path
if not os.path.exists(csv_file):
  print "Error, el archivo no existe"
  return

#Open the file on read only mode
input = open(csv_file,'r')

#Create a reader object from the CSV module
reader = csv.reader(input)

#Read the file
for row in reader:
    #Print the line
    print ', '.join(row)
```
We already know how to create shapefiles and read csv files, the next step would be to create the features, so we must transform the polar coordinates to rectangular and it is at this point that for me things get a little dark so forgive the errors that you can find.
To make the coordinate transformation we’ll convert the decimal angle in radian angle. Gustavo in his post how to generate a polygonal (in Spanish) between the files to download you can find a PDF that provides an explanation of the calculations he made, if anybody has doubts I recommend to read it. I only want to clarify that we ‘ll use the python module python math to use math functions sine and cosine, needed to perform the transformation. In addition, our course uses relative coordinates, so we need a starting point and the code to calculate the new coordinates from the above ones. Our starting point is ( X= 361820.959424, Y = 1107908.627000). The source code would be:
```
"""
Convert decimal degrees, minutes, seconds to radian
"""
import math
#Define the “pi” value
PI = 3.1415926

x_ant = 361820.959424
y_ant = 1107908.627000

#Apply the equation and obtain the angle in radians
angulo = (degrees+(minutes/60.0)+(seconds/3600.0))*PI/180.0

#Convert the polar coordinates into rectangular ones

x_new = radio * math.sin(angulo)
y_new = radio * math.cos(angulo)

#Add relative coordinates values to get the next coordinate
x = x_new + x_ant
y = y_new + y_ant
```
The last piece of our puzzle is to learn how to create the features and their geometries. The layers that we created earlier shape_line and shape_polygons have a method called append that allows us to add the features to the layer. This method accepts a dictionary,
python dict that uses as key fields the ones we defined in the data structure of the layer (defined when we created it). The values are the ones that should have the feature. The geometries will be created using the geometric module geom from the scripting extension, in particular the createGeometry function, that needs the type of geometry to be created and the dimensions of the geometry. The code that we could use is:
```
geometry_multiline = geom.createGeometry(MULTILINE, D2)

values = dict()
values["ID"] = id #Calculated field for the registered number
values["LINEA"] = linea_id #First data of the course
values["GRADOS"] = grados #decimal degrees from the course
values["MINUTOS"] = minutos #decimal minutes from the course
values["SEGUNDOS"] = segundos #decimal seconds from the course
values["DISTANCIA"] = radio #Distance from the course
values["RADIAN"] = angulo #Radian angle calculated
values["X"] = x #X coordinate calculated
values["Y"] = y #Y coordinate calculated

shape_line.append(values)
```
At this point we have seen everything needed to get what we want from our original course, we only need to assemble the puzzle and the final result would be this:

Polygon generated from the course

The final source code can be downloaded from here .

We hope you enjoy that exercise as much as I do.

See you next time!

Filed under: english, gvSIG Desktop, scripting
2:03
Marco Bernasocchi: Getting closer to taming the snake
sur Planet OSGeo

very geeky but I have to post this:

D/Qt (27512): src/python/qgspythonutilsimpl.cpp: 188: (runString) COMAND OK: import sys D/Qt (27512): src/python/qgspythonutilsimpl.cpp: 188: (runString) COMAND OK: import os D/Qt (27512): src/python/qgspythonutilsimpl.cpp: 188: (runString) COMAND OK: sys.path = ["/data/data/org.qgis.qgis/files/share/python","/data/data/org.qgis.qgis/files//python","/data/data/org.qgis.qgis/files//python" + "/plugins","/data/data/org.qgis.qgis/files/share/python/plugins"] + sys.path D/Qt (27512): src/python/qgspythonutilsimpl.cpp: 91: (initPython) newpaths: "/data/data/org.qgis.qgis/files/share/python","/data/data/org.qgis.qgis/files//python","/data/data/org.qgis.qgis/files//python" + "/plugins","/data/data/org.qgis.qgis/files/share/python/plugins" D/Qt (27512): src/python/qgspythonutilsimpl.cpp: 188: (runString) COMAND OK: from sip import wrapinstance, unwrapinstance D/Qt (27512): src/core/qgsmessagelog.cpp: 45: (logMessage) 2013-05-21T01:57:20 [0] Python support ENABLED
20 mai 2013
21:15
OpenGeo Blog: New Job Postings
sur Planet OSGeo

OpenGeo is looking for talented people to join our team. We offer interesting technical work, competitive salaries, great benefits, and a fantastic working environment. Most importantly we challenge our employees to build the best open source and interoperable tools for spatial data on the web. We added a few new posts this week, if any look like a fit for you, please apply!

Here’s a list of our open positions:

UX Developer - We’re seeking a talented user experience developer to design and implement creative user interfaces for our innovative open source geospatial software.

Support Manager - OpenGeo is looking for a support manager to ensure that customers large and small are familiarized with our software, properly trained in its function, and supported if anything should go wrong. The ability to think quickly and communicate clearly in a fast-paced environment is essential. Enthusiastic problem-solving skills and a desire to be engaged at all levels of a problem are even better.

Software Project Manager - OpenGeo is seeking a skilled Software Project Manager to help us bring open source software to governments, commercial enterprises, NGOs, and other organizations around the world.

Java Developer - OpenGeo is seeking skilled software engineers interested in helping us bring open source software to organizations around the world. Our team improves the open source components underlying the OpenGeo Suite, allowing a wide variety of customers to share and edit data using open standards.

Front End Developer - We’re looking for someone who is ready to work with peers in design and engineering to create pixel-perfect interfaces across a range of projects and products. You’ll own the code-base, work on the hard problems, build your ideas into reality, and help determine best practices throughout our organization.

Sales Account Manager – Our current (and future) clients are looking to open source to solve their spatial IT needs. Our account managers help commercial enterprises and federal clients use our innovative, open source geospatial software as efficiently and effectively as possible, allowing them to get more than ever out of their geospatial instances.

Here’s the full list, please apply and/or spread the word!
20:57
gvSIG CE: 4 developers more with write access to our SVN
sur Planet OSGeo

Dear all,
if you haven't followed the gvSIG CE developer list, maybe you don't know that we have now 4 new developers with write access to our SVN. All of them are well known FOSSGIS developers:

- Victor Gonzalez is a Computer Engineer by the Valencia Politechnical University. Victor was awarded with the 52º North Student Innovation Prize in 2009 with the project “SQL Script Profile for 52°North WPS-T”. He has participated in projects like GearScape, GGL, or gvSIG. He is making an amazing work in gvSIG CE since more than one year developing new functionalities, hunting bugs, working on the integration of GeoTools in gvSIG CE, getting the code base into better shape, etc.:
- Export map layouts to raster formats
- Geotools integration methodology
- clean-up work

- Jorge Arévalo is a Computer Engineer by Universidad Autónoma de Madrid, UAM. He has been collaborating with PostGIS and GDAL creating the PostGIS Raster GDAL driver. He has been solving some GDAL related open cases. gvSIG CE has now an amazingly good GDAL drivers support.

- Micho Garcia studied Ocean Sciences at the Vigo University, and has devoted his professional live to GIS development. He has been updating the EPSG database

- Francisco Puga is an ICT engineer by formal training and has participated in several NGOs related to technology, development and free software. He has sent us some patches for the java version of SEXTANTE:
- Models are not loaded by means of the "load button" in the settings
- GridCalculator does not work with models in batch mode
- Error in sextante.history file prevent use the toolbox

We really appreciate the work you are doing.
See you soon
Jose Canalejo
18:31
Marco Bernasocchi: python support in qgis is getting there
sur Planet OSGeo

Never been so close, but it took the heck out of me… now lets see if after 4 days of continuous fiddling around I manage to tame the snake
16:39
Free and Open Source GIS Ramblings: TimeManager in QGIS 2.0
sur Planet OSGeo

Today, I updated my QGIS Time Manager plugin to version 0.8. It now works with the QGIS 2.0 API and that means that we can take advantage of all the cool new features in our animations. The following quick example uses the “multiply” blend mode with the tweet sample data which is provided by default when you install the plugin:

(The video here is a little small. Watch it on Youtube to see the details.)
16:00
Nathan Woodrow: Alpha in QGIS colour ramps. Oh yeah!
sur Planet OSGeo

Here is a preview of a new cool feature coming in QGIS 2.0. Alpha channel in colour ramps.

Fancy!

The best part is it even works on raster layers.

How bloody awesome is that!

Mathieu Pellerin made a cool made showing of this new feature on our flickr map group
13:28
Simone Giannecchini: Fun with MapStore: Italian UNESCO Sites as OpenData
sur Planet OSGeo

Dear All,
there days the Italian UNESCO Sites of interests have been released as OpenData via this portal (NOTICE; we were not involved :)).

The data can be downloaded, there are WMS and WFS end endpoints available (using GeoServer), and there is a small webgis based on OpenLayers (which could actually be improved a litlle bit ;) ).
Well, OpenData + Open Services, this is really nice so I thought I could share a map I created with the cloud version of MapStore the same data with proper querying capabilities and so on.

So there you go, here below you can find a pretty simple map that just shows our UNESCO items, you can embed it in your site with the following HTML code:

<iframe height="400" src="http://mapstore.geo-solutions.it/mapcomposer/viewer?locale=en&bbox=-1851508.8592676,4102979.8193213,4351508.8592676,7429519.2898291&mapId=356" style="border: none;" width="500"></iframe>

Next steps would be customizing the info boxes and probaly adding more markers (get some info here) but I guess for the moment this is enough from us :). Ah yeah, I would probably also make good use of the buffer WMS parameter of configuration to make sure symbologies don't get cut in tiled development, here is some additional infomation.

Visit our online demo or download the MapStore binary, read the Quick Start guide and start to create and share your own maps. If you need more info, please check to the complete documentation wiki.

If you have questions or if you just want to talk to us about using our tools in your project, please, subscribe to the mailing list here. In any case, do not hesitate to contact us.

Happy mapping to everybody!
The GeoSolutions team,
7:31
gvSIG Team: gvSIG 2.0: Biblioteca de símbolos “Forestry”
sur Planet OSGeo

Uno de los ámbitos habituales de uso de los SIG es el forestal. Orientada a esos casos de uso hemos realizado una nueva biblioteca de símbolos. Y como es habitual disponible desde el “Administrador d e complementos”.

Veamos como hemos realizado esta biblioteca, de modo que sirva como un nuevo ejemplo a los usuarios para crearse las suyas propias.

Para los símbolos puntuales (marcadores) hemos partido de dos fuentes distintas:

- Por un lado la colección de símbolos utilizada por el NPS (U.S. National Park Service). Una excelente colección de símbolos de dominio público.

- Por otro lado hemos utilizado la fuente Trees & Shrubs realizada por Jim Mossman, también de dominio público.

Para añadir los símbolos de NPS, hemos seguido lo indicado en este post. Para facilitar la identificación de símbolos, hemos utilizado una herramienta de renombrado masivo de archivos, ya que el nombre que gvSIG da a cada símbolo es el nombre del fichero; en nuestro caso hemos utilizado pyRenamer. Mediante Inkscape hemos generado los distintos símbolos de selección (coloreando de amarillo cada símbolo y añadiendo la terminación “_sel” al nombre del fichero).

Todo preparado para utilizar el importador de símbolos de gvSIG. Importamos los símbolos a “Forestry/NPS”. De forma automática se crea la nueva biblioteca con el conjunto de símbolos puntuales importados.

A partir de lo indicado en este otro post generamos los distintos ficheros SVG que representan un conjunto de árboles y arbustos. Utilizamos el importador de símbolos, almacenándolos en Forestry/Trees & Shrubs.

Además de símbolos puntuales, queríamos que esta biblioteca contuviera un conjunto de símbolos de líneas y de relleno habituales en los mapas forestales.

Hemos generado tanto símbolos lineales:Como símbolos de relleno:

Ya sólo nos queda crear el paquete tal y como explicamos en este p ost.

Este paquete lo tenéis disponible desde el administrador de complementos (seleccionando la URL http://downloads.gvsig.org/download/gvsig-desktop/ y buscando por “Tipos/symbols”)o directamente descargándoos el paquete desde aquí.

Filed under: gvSIG Desktop, spanish Tagged: gvSIG 2.0
5:33
GeoServer Team: GeoServer 2.3.2 released
sur Planet OSGeo
The GeoServer team is pleased to announce the release of GeoServer 2.3.2 for download.
- This release includes and is made in conjunction with GeoTools 9.2.
- The INSPIRE plugin has now graduated to extension and is included in this release. This plugin adds WMS and WFS capabilities support for metadata required for compliance with the European INSPIRE directive.
- The application schema support (app-schema) support plugin now enables joining by default for data sources that support it.
- Fixed transformation problems with projections based on Hotine Oblique Mercator (variant B) (for example Swiss CH1903 / LV03)
- Fixed WFS lockups when a WFS 1.1 GetFeature is providing a schema referring back to the same server DescribeFeatureType
- A new option to limit the file browser to the data directory, geared towards high security/multi-tenant environments
More details can be found in the GeoServer 2.3.2 Release Notes.
5:22
GeoTools Team: GeoTools 9.2 Released
sur Planet OSGeo
GeoTools 9.2 ReleasedThe GeoTools community is pleased to announce the availability of GeoTools 9.2 for download from SourceForge:
This release has also been deployed to the OSGeo Maven Repository.

Please see the Release Notes for details. This release is made in conjunction with GeoServer 2.3.2.

In addition to bug fixes:
- The application schema support (app-schema) module now enables joining support by default for data sources that support it; this improvement and many bug fixes by Rini Angreani.
- XML parser support for unsigned numeric bindings has been added by Justin Deoliveira.
- Fixed transformation problems with projections based on Hotine Oblique Mercator (variant B) (for example Swiss CH1903 / LV03)
We would like to thank all contributors for making this release possible.

This release was brought to you by Ben Caradoc-Davies from CSIRO.
About the 9.x SeriesHere is a summary of the new features for the GeoTools 9.x series:
- Native geometry serialisation has been added for SQL Server.
- Feature Collection Clean up: removed methods that were only applicable for in memory feature collections, combined with a general quality assurance review.
- Vector Grid module is now included as an extension.
- The gt-complex module provides general programming support for complex features.
- Library supports the use of Java 7 try-with-resource syntax.
- PostGIS, Oracle and Property files now provide Partial 3D data support backed by the introduction of ReferenceEnvelope3D.
- WMS 1.3.0 client support now enabled by default.
- OGC models and XML support for WCS 2.0 and OWS 2.0.
Dependencies:
- ImageIO-Ext 1.1.6 and JTS 1.13 release
For more information on GeoTools 9.x series
- GeoTools 9.1 Released ( Release Notes )
- GeoTools 9.0 Released ( Release Notes )
- GeoTools 9.0-RC1 Released ( Release Notes )
- GeoTools 9.0-beta1 Released ( Release Notes )
- GeoTools 9.0-M0 Released ( Release Notes )
Getting Started with GeoToolsGeoTools is an Open Source Geospatial Foundation project helping Java developers work with geospatial data. For a complete list of features please see the project overview included in our documentation.
If you would like to get started with GeoTools a Quickstart is available (covering Eclipse, NetBeans and command line Maven use). Additional tutorials and build instructions are included in the user guide.
GeoTools 9.x is the current stable series with a release scheduled each month. This level of service is part of our six month timed release cycle. We are always interested in volunteers - if you are in position to assist please stop by geotools-devel and lend a hand.
If you are upgrading from a previous version of GeoTools please review the upgrade instructions, as there has been some API changes around the use of FeatureCollection and ReferencedEnvelope.

Thanks for using GeoTools!
19 mai 2013
20:53
Paulo van Breugel: Rounding of floating numbers in GRASS GIS r.mapcalc
sur Planet OSGeo

The GRASS GIS development team keeps on introducing new features and enhancements to GRASS 7.0. One of the latest examples is the enhancement of the round() function in r.mapcalc. Previously this function would always returns an integer, regardless of its … Continue reading →
16:00
Nathan Woodrow: On being an open source contributor
sur Planet OSGeo

Joining an open source project has been one of the best things I did for my career. To better myself in the process of improving QGIS. To grow as a GIS professional. To learn to be part of team and respect each others ideas even if don't agree. To be open to ideas that others have spent a lot of time on. To not just be single tool pusher and learn a wider range of toolkits. To work with people who you have never seen in person, or even talked to.

How did it feel to join an open source project? Scary but awesome I would say. Scary in that that everyone would read my code - my very amateur code. Scary in that I had never really joined an open source project before and wasn't sure what everyone would think of my work, or my ideas.
Scary because there are so many people better at this than me and they might think I'm crap.

However all of this fear is outweighed by the awesome feeling of knowing that people benefit from the work you, and the rest of the team, put in. Sometimes even the small things can make a huge difference to what people can do with your software - and yes I did use "your software" on purpose. Contributing to open source means you, personally, are part of the software. Being a contributor, for me at least, gives you a deeper relationship with the project. The kind of relationship that sees you staying up at night when the rest of the family is in bed trying out a new idea, fixing some annoying bug, or writing a blog post about being an open source contributor. All for free! - well mostly. Some call it obsession I prefer passion.

It's not pretty roses all the time. Passion can lead to burnout. Trying to be involved in most of the major parts of the project can result in stretching yourself thin. A project that never sleeps makes this even harder. The wave of ideas can sometimes be a distraction from just getting stuff done. Rejection of your work can be hard to handle the first time, you just have to remember it's never personal. Most of these are just personal demons that need to be managed but they do sneak up if you enjoy what you do. Having a family - and an xbox - helps to ground you and make sure you don't spend all your free time on the computer hacking away.

Like I said, and despite personal demons, joining an open source project has been one of the best things I did. There is an emotional kick working on something and seeing it used by other people. I didn't expect my expression based labeling addition would get such good remarks but it did and that helped push me further into becoming a QGIS contributor.
17 mai 2013
19:09
Jackie Ng: MapGuide tidibts: The resource dependency chain
sur Planet OSGeo

You probably know in MapGuide that there is a whole different bunch of type of resources available at your disposal, when authoring up your data, maps and applications.

You probably also know that if you move, rename or delete a resource you may be affecting and/or breaking other resources that depend on it.

How about the big picture? Well here's one I've prepared earlier.

As you can see, with the exception of the Load Procedure, Application Definition and Web Layout, every other resource type has a dependency on another resource type.

Consider what you may be potentially breaking when you move, rename or delete a given resource.
9:11
gvSIG Team: gvSIG 2.0: Symbols library “OSM”
sur Planet OSGeo

Does anyone ignore what is OSM (OpenStreetMap)? If anyone was distracted, OpenStreetMap is the most important participative project to create free and editable maps worldwide.

Following step by step what has been described in the posts “gvSIG 2.0: Create symbols libraries” we have created a new symbols library for our gvSIG form symbols related to OSM. Availability of this library has to be framed in the idea that gvSIG users can use a wide and differentiated symbols library sets, that can be installed through the “Add-ons manager”.

See how this library has been realised in order to be a new example for users who wish to create an own library.

For point symbols (markers), a collection made by “SJJB Management” under Creative Commons (CC-0) licence and called “SJJB SVG Map Icons” has been used. It is an excellent categorized symbols collection that can be downloaded in SVG format. Some of these icons come from the “US National Park Service Cartography” and other source of public domain that can be browsed on SJJB website.

As stated in previous posts, the name assigned by gvSIG to each symbol is the file name, thus we have used a massive file renaming tool to perform this task; in our example we have used pyRenamer, available for Linux. Using Inkscape we have produced the different symbols when selected (colouring in yellow each symbol and adding the suffix “_sel” to file name).

Everything is ready now for the gvSIG symbols loader as already seen in a previous post and the new library is created in an automatic way and with the point symbols set loaded. In this case we have decided to create some subfolders to classify the sets of symbols.

We want that this library have also lines and polygons symbols similar to the ones we can found in OSM. Even if no documentation on symbols composition is available, it is possible with any image editor, such GIMP, to identify the symbols RGB values and replicate them in gvSIG.

We have created also line symbols

and polygon symbols

Only the package creation is left and “how to do it” is explained in this post.

This package is available in the add-ons managers (selecting [downloads.gvsig.org] and looking for it in “Categories/simbology”) or directly downloading from here.

Filed under: english, gvSIG Desktop, training
8:00
Cameron Shorter: Open Letter to OGC re Geoservices REST API
sur Planet OSGeo
This page aims to collate community concerns related to the adoption of the "Geoservices REST API" document as a standard of the Open Geospatial Consortium (OGC). The page has been collaboratively edited, and delivered by the board of the OSGeo Foundation (OSGeo) to the OGC and OGC voting members on Friday 17 May 2013.
The original document can be found here: [wiki.osgeo.org]
Cover Letter from the OSGeo Board
The board of the Open Source Geospatial Foundation (OSGeo) is presenting this letter to the OGC. The letter highlights concerns about the "GeoServices REST API" from many people within the OSGeo community. As always, if there is anything the OSGeo board can do to help, then please let us know.
Signed: Jeff McKenna (OSGeo president), Peter Batty, Jáchym Cepický, Michael Gerlek, Anne Ghisla, Mark Lucas, Daniel Morissette, Cameron Shorter, Frank Warmerdam
Open Letter to OGC and voting members
May 2013
We, the undersigned, have concerns that approving the "Geoservices REST API" as an OGC standard, will have detrimental impacts on interoperability within the spatial industry.
We strongly urge that the proposed "Geoservices REST API", as it stands in May 2013, be rejected as an OGC standard.
People have listed different reasons for concern. These concerns are described below.
Signed
1. Cameron Shorter, Geospatial Solutions Director at LISAsoft, core contributor & coordinator of OSGeo-Live, OSGeo Board member
2. Mark Lucas, Founding member and board of directors for OSGeo foundation, Principal Scientist for RadiantBlue Technologies Inc.
3. Stephen Woodbridge, Director of iMaptools.com, Contributor and/or PSC of Mapserver, pgRouting, PAGC, and PostGIS
4. Even Rouault, Geospatial developer, OSGeo Charter Member, core contributor and PSC member of GDAL/OGR, contributor of Mapserver, PROJ.4, libgeotiff, shapelib, libtiff
5. Gerhard Triebnig, Managing Director at EOX IT Services GmbH
6. Brent Wood, Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
7. Stephan Meissl, CTO at EOX IT Services GmbH, contributor to Mapserver, PSC chair of EOxServer
8. Jeroen Ticheler, Director of GeoCat, project founder and PSC chair of GeoNetwork opensource
9. Just van den Broecke, Director at Just Objects, contributor to Heron Mapping Client, secretary of OSGeo Dutch Local Chapter, member at OpenGeoGroep
10. Milo van der Linden, member at OpenGeoGroep
11. Landon Blake, GIS Department Manager/Land Surveyor at KSN, OSGeo California Chapter Board Representative.
12. Daniel Morissette, President at Mapgears, OSGeo Board member, core contributor and PSC member of Mapserver and GDAL/OGR. Former OGC TC member and involved in the implementation of several OGC WxS specs in MapServer.
13. Bob Basques, GIS Systems Developer at the City of Saint Paul, MN. Public Works GIS (GISmo), Technical Director at SharedGeo, OSGeo Charter Member, OSGeo TCMUG local chapter member, Co-founder and PSC member of GeoMoose project.
14. Pedro-Juan Ferrer Matoses, PM at Omnium Strategic Intelligence, Spain, OSGeo Charter Member, OSGeo Spanish Local Chapter Liaison officer.
15. Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
16. María Arias de Reyna, software engineer at GeoCat, Spain, member of OSGeo Spanish Local Chapter.
17. Anne Ghisla, OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
18. Micho Garcia, Freelance and member of geomati.co, Spain, member of Spanish Local Chapter
19. Margherita Di Leo, OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
20. Jorge Sanz, GIS Consultant at Prodevelop, OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
21. Pablo Sanxiao, CTO and co-founder at iCarto, OSGeo Spanish Local Chapter Member, Spain
22. Frank Steggink, GIS software developer at Vicrea, The Netherlands, member of the Dutch Local Chapter
23. Olivier Courtin, Oslandia co-founder, core contributor or/and PSC member of Mapserver and PostGIS. OGC TC member.
24. Wladimir Szczerban, OSGeo Spanish Local Chapter Member, Spain
25. Anita Graser, GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
26. Volker Mische, geospatial software engineer, creator of GeoCouch
27. Iván Sánchez, OSGeo Spanish Local Chapter Member, head of OpenStreetMap Spain, OpenStreetMap Foundation member, Humanitarian OpenStreetMap Team member, Spanish SDI working group member
28. Gabriel Carrión, Strategy Manager at gvSIG association
29. Sandro Santilli, OSGeo Charter Member, PostGIS and GEOS PSC member and core hacker.
30. Javier Diaz, member of Geoinquietos Bs As [1], member of the Organizing Committee FOSS4G Bs As 2013 [2]
31. Jo Cook, Consultant at Astun Technology, former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of FOSS4G 2013
32. Francisco José Peñarrubia, CTO and co-founder at SCOLAB. Members of gvSIG Association
33. Shanmugam Ganeshkumar, Director of GeoICON, member OSGeo Malaysia Chapter
34. Barry Rowlingson, Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
35. Stefan Keller, University of Applied Sciences, Rapperswil (Switzerland), Member of Swiss OSM (SOSM) and QGIS association and of organizing committees of pgConf.DE and FOSSGIS 2013, and member of eCH (e-government standards of Switzerland)
36. Andrew Bailey, OSGeo member, Astun Technology
37. Suchith Anand, OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
38. Carlos Krefft, GIS software developer at CSTARS - University of Miami, OGC and OSGeo Member.
39. Stefano Costa, OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
40. Peter Baumann, Jacobs University, OGC member, WCS.SWG chair, editor of 10+ specs (disclaimer: this is an expression of my personal opinion and not in any way endorsed by OGC)
41. Peter Batty, CTO of Geospatial Division at Ubisense, OSGeo board member, former CTO of Intergraph and GE Smallworld, Technical Committee member of OGC in its formative years c 1995-97
42. Barend Köbben, OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at ITC-University of Twente
43. Paolo Cavallini, Faunalia, OSGeo member, GFOSS.it member and former president, QGIS-PSC
44. FRans Thamura, Indonesia, OSGeo Indonesia, organizer]
45. Sanghee Shin, Founder and CEO of Gaia3D, OSGeo Charter Member, Representative of OSGeo Korean Chapter, Chairman of Open Source GIS Alliance Korea
46. Benni Purwonegoro,Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
47. Jachym Cepicky, Czech Republic, member of OSGeo Board of Directors
48. Pat Cappelaere, Vightel Corporation
49. Jürgen Fischer, norBIT GmbH, QGIS core developer
50. Maria Antonia Brovelli, OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at Politecnico di Milano, Italy
51. Nacho Varela, GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
52. Vasile Craciunescu, OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
53. Abbas Abdul Wahab, Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
54. Roy Braam, Software Engineer @ | B3Partners
55. Peteris Bruns, Latvia, GIS Consultant & Software Engineer @ | SunGIS
56. Giovanni Manghi, Portugal, Faunalia, OSGeo member, OSGeo-Portugal
57. Hugo Martins, UK, Lutra Consulting, WebGIS Developer, OSGeo-Portugal Member
58. Saber Razmjooei, UK, Lutra Consulting, Co-Founder
59. Peter Wells, UK, Lutra Consulting, Co-Founder
60. Sidney Gijzen, The Netherlands, Researcher GIS @ Alterra, Wageningen UR
61. Miles Fidelman, US, Principal, Protocol Technologies Group, LLC
62. Puneet Kishor, OSGeo Charter Member; Geology, Univ. of Wisconsin-Madison; Creative Commons
63. António José Silva, Portugal, GIS Consultant, OSGeo-Portugal Member
64. AndreMano, Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
65. Mauricio Miranda, Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
66. Paulo Machado, Portugal, Software Engineer @ PT Inovação
67. Alvaro Anguix, Spain, General Manager at gvSIG Association
68. Santiago Higuera, CEO at Mercatorlab, OSGeo Spanish Local Chapter Board Member, Spain
69. Alan Boudreault, Developer at Mapgears, contributor to Mapserver and GDAL/OGR.
70. Mike Saunt, UK, Owner at Astun Technology Ltd, OSGeo sponsor
71. Michael Smith, OSGeo Charter Member, Physical Scientist US Army Corps of Engineers Remote Sensing GIS Center
72. Angelos Tzotsos, OSGeo Charter Member, Researcher at National Technical University of Athens
73. Michaël Douchin, France, GIS consultant & software engineer at 3liz
74. Pedro Venâncio, Portugal, GIS Analyst @ Municipality of Pinhel
75. Jorge Gustavo Rocha, Portugal, GIS Professor at Universidade do Minho
76. Daniel Kastl, Japan, Georepublic, Founder
77. John Callahan, US, Research Scientist and GIS/Remote Sensing Specialist, University of Delaware
78. Kalyan Janakiraman, Senior Systems Analyst, Business Development Services, NSW Land and Property Information, Sydney, Australia
79. Phillip Davis, Director, National Geospatial Technology Center of Excellence, Texas, USA
80. Simon Pigot, contributor to and PSC member of GeoNetwork opensource (speaking for myself, not an official view of my employer)
81. John Bryant, Consultant, Mammoth Mapping, Dawson City, Canada and GIS/DB Admin, Jupiter Mines, Perth, Australia
82. Christos Iossifides, Remote Sensing Instructor, Laboratory Teaching Staff, Remote Sensing Instructor and Researcher, National Technical University of Athens
83. Tim Bowden, Spatial Consultant, Perth, Australia
84. Luca Delucchi, GIS Technician, Trento, Italy
85. Bart van den Eijnden, GIS software developer, Utrecht, Netherlands
86. Henry Addo, Software Developer at Ushahidi [3], contributor of OSGeo-Live
87. Stefano Iacovella, GIS consultant & software engineer, Rome, Italy
88. Meine Toonen, Software Engineer @ B3Partners, The Netherlands
89. Arne Kepp, Software Engineer, Oslo, Norway
90. Pirmin Kalberer, Managing director Sourcepole, FOSSGIS member, Contributor of GDAL/OGR, QGIS, Mapfish, UbuntuGIS, OSGeo-Live, Switzerland
91. Dr. Horst Düster, Managing director Sourcepole, FOSSGIS member, Treasurer QGIS Project QGIS, Zürich, Switzerland
92. Richard Duivenvoorde, Managing director & software developer Webmapper, QGIS community member
93. Steven Feldman, Principal at KnowWhere Consulting and Chair of the LOC for FOSS4G 2013
94. Edward Mac Gillavry, Managing director & software developer Webmapper
95. Maxim Dubinin, CEO at NextGIS, head of GIS-Lab.info
96. Fran Boon, PMC Chair at Sahana Foundation, CTO of AidIQ
97. Ian Edwards, Chair OSGeo:UK
98. Dmitriy Baryshnikov Developer at NextGIS, GDAL/OGR committer, wxGIS developer, GIS-Lab.info community member
99. Chris van Lith, Director B3Partners, member of OpenGeoGroep
100. Vincent Picavet, co-founder of Oslandia, founding member and treasurer of OSGeo-FR
101. Stefan A. Tzeggai, creator of AtlasStyler SLD editor, founder of empirica systeme gmbh
102. Roald de Wit, Geospatial Software Engineer, Melbourne, Australia
103. Manuel Grizonnet, working at the French Space Agency, ORFEO ToolBox library developer
104. Toru Mori, President & CEO, Orkney, Inc., Yokohama, Japan, Representative of OSGeo Japan Chapter, OSGeo Charter Member
105. Markus Schneider, TMC chair of the deegree project, CEO of Occam Labs
106. Elena Mezzini, Remote Sensing and GIS Technician, GFOSS.it member, Bologna, Italy
107. Alexander Bruy, NextGIS, QGIS core developer
108. Danilo Furtado, Portugal, OSGeo member, OSGeo-Portugal
109. Andreas Schmitz, Germany, deegree core developer and TMC member, CTO of Occam Labs
110. Oliver Tonnhofer, Germany, MapProxy core developer, founder & CTO of Omniscale
111. Thomas Baschetti, Germany, Freelancer, Mapbender PSC Member, FOSSGIS member
112. Ian Mayo, GeoSpatial developer, UK
113. Ivan Mincik, CEO of GISTA s.r.o., Slovakia
114. Edmar Moretti, Software developer, i3GEO core developer, Brazil
115. Diego Moreira, GIS Analyst, Contributor of QGIS, Brazil
116. Luigi Pirelli, Freelance Analyst/Programmer, co-founder of Italian OSGEO Local Chapter GFOSS.it, Italy
117. Kyle Shannon Software Developer, contributor of GDAL/OGR, United States
118. David Mateos, worker member at Terrativa S. Coop. and OSGeo Spanish Local Chapter Member, Spain
119. Luis Franco, researcher and GIS analyst at the University of Santiago de Compostela, Spain
120. Gabriel Roldan, Software Developer, Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Member
121. Dimitris Kotzinos, OSGEO Charter Member, OSGEO Greek Chapter founder, Assistant Professor TEI of Serres, Greece
122. Stefan Steiniger, owner of GEO Steiniger Ltda., contributor to OpenJUMP GIS and OpenTripPlanner and author of several FOSS4G overview articles, Canada/Chile
123. Nobusuke Iwasaki, Senior Researcher, National Institute for Agro-Environmental Sciences, Tsukuba, Japan, OSGeo Japan Chapter Board Member
124. Ross Johnson, Land Information Officer, City of Ryde Council and NSW Committee member of Surveying & Spatial Sciences Institute (SSSI)
125. Kumaran Narayanaswamy, CEO & Managing Director of kCube Consultancy Services Pvt Ltd India.[4], Member of India OSGeo Chapter.
126. Luis Fernando Bueno, Professor at Federal University of Rondonia, researcher and GIS analyst, Brazil.
127. Bob Bruce, FEC, P.Eng., Geomatics Engineer, Winnipeg, Manitoba, Canada.
128. Moritz Lennert, Researcher in geography at the Free University of Brussels (ULB), GRASS-PSC
129. Ian Turton, Software developer and open standards advocate, GeoTools-PSC
130. Gérald Fenoy, OSGeo Charter member, Founder and CEO of GeoLabs SARL, France
131. David Bitner, OSGeo Charter member, OSGeo VP for Geodata, OSGeo Twin Cities Chapter, Sahana Software Foundation Board of Directors, MetroGIS Coordinating Committee Chair, ownerdbSpatial
132. Peter Löwe, OSGeo Charter member, Senior Researcher at Deutsches GeoForschungsZentrum GFZ, General Manager GISIX.com
133. Gavin Fleming, OSGeo Charter member, owner of AfriSpatial.
134. Frank Maes, GeoICT professional, Head Operations at Geosparc, Contributor & community member of Geomajas, OSGeo member
Summary
The OGC candidate standard titled "GeoServices REST API" is currently, in May 2013, being considered to be approved as an Open Geospatial Consortium (OGC) standard. The vote to accept the document as a standard is unusually contentious. The controversy is the cause of this open letter.
The candidate standard was previously released for public comment and can be found on the request for public comment page (though public comment has been closed for now).
The candidate standard attempts to standardize a suite of web services such as a service which provides map images, a service which provides geospatial feature data, and a service which performs geospatial processing. The candidate standard focuses on interactions via a defined hierarchy of URLs and using predominantly a particular set of JSON schemas for the exchange of geospatial data.
Criticism and Response
The criticism of the adoption of this particular document as an OGC Standard includes a wide variety of reasons such as:
- the OGC's process through which the document was developed which is thought to lack sufficient flexibility to respond to input from various stakeholders,
- the focus of the document on 'REST' and 'API' which is seen as not matching the ideas others have for these concepts,
- the names of the standard and of the services which are seen as potentially confusing,
- the functionality of the new services which are considered to duplicate that of existing services already standardized by the OGC such as WMS, WFS, WCS, and WPS,
- the addition of a new set of services based on new URL patterns and new JSON exchange formats which is seen as duplicating the efforts of other working groups bringing similar ideas to the updates of existing OGC services,
- the re-introduction in the new services of previously resolved interoperability issues which is seen as failing to build on the existing knowledge and experience,
- the use of the particular JSON schemas which are seen as having little industry acceptance and are incompatible with other widely used schemas, and
- the lack of implementation diversity which is thought to give the vendor of the one complete implementation an unusual commercial advantage on top of the vendor's already dominant position in the domain.
These issues have potential impacts on the use of 'Open Standards' by governments and companies, on the interoperability of software interacting with standards compliant OGC services, on the costs to developers and users of standards compliant software, on the understanding of 'Open Standards' by the public at large, and, possibly, on the reputation of the OGC as a champion of interoperability.
In particular there are concerns by some that adoption of the standard will likely result in a combination of the following:
1. The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
2. Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
3. Sponsors (such as governments) who require compliance with OGC standards will discover that applications don't communicate together, due to applications supporting different OGC standards that essentially do the same thing.
4. This will result in a diminished importance of OGC, as the "OGC standards" stamp of approval will not equate interoperability.
5. After a while, in order to solve interoperability issues, a respected international organisation or program will likely take the initiative to mandate one standard as the preferred standard for all agencies to follow. To date, the OGC has provided this leadership.
6. One standard taking prominence over the other will likely lead to the other being neglected or deprecated, resulting in many OGC compliant systems becoming legacy systems in the process. This should be considered an undesirable outcome for a standards organisation.
In response to these issues, the authors of the Geoservices REST API document have stated that:
- the process of the OGC has been followed completely,
- the specification actually is RESTful and does define an API,
- the name, due to the controversy, is open for modification
- the OGC does not forbid duplication of service functionality, already has duplication between the W*S and the S*S (sensor) family of standards, should not block progress in the name of 'one true way', and harmonization between the services can be considered in the future,
- the JSON format exists and functions, and
- there are alternative implementations for some of these services.
The authors also stress that the existence of a large user base shows the service is useful, and that the standardization of the services at the OGC may encourage new implementations.
The SWG has published two documents in response to various comments.
- File:OGC 12-642 GeoServices REST API - RFC Comments Response.pdf presents the responses from the Standards Working Group to the comments received from the public during the public Request for Comments (RFC).
- File:OGC 13-031r1 GeoServices REST API - Response to no votes r1.pdf presents the responses from the Standards Working Group to the reasons given by the organizations voting _no_ during the adoption vote.
Positions on the vote
The discussion raises a number of issues, many based upon complex technical concepts and implications. This makes it difficult for voting OGC members considering whether to support (or not) the "Geoservices REST API" as a standard. The following provides one analysis of the positions on the vote, aimed to simplify and summarize key points. However, it does not necessarily represent the opinions held by all signatories above.
The pros for accepting the "Geoservices REST API" document as an OGC standard
- The OGC should be in the business of developing good standards, not in choosing which standards should be implemented.
- The proposers of the document want to make a standard and have followed all the rules of the OGC. The work of any such group of members deserves serious, good faith consideration.
- The need for an integrated suite of services using simple data, which is addressed (partially) by the document, is real. The proposed document is pushing the OGC on this issue.
- The proposed document could be useful to a number of people.
- The proposed document is not significantly more broken than the existing standards of the OGC. As one author of standards notes:
"I know how totally impossible it is to write a good standard, so the weaknesses in the existing document seem more acceptable."The cons
- The OGC actually is, whether it should be or not, in the position of recommending interoperable standards for geospatial services. The proposed document is not good enough, has implementations dominated by one vendor's server implementation, and not publicly supported enough, to be considered at the same level as existing standards.
- Adopting a standard implies a desire to maintain the standard, but OGC's desire to support this approach has been questioned by some. In particular, the lack of collaboration and willingness to accept recommendations from the community on this version of the "Geoservices REST API" document bodes ill for the future.
- The overlap in functionality between the proposed services and the existing services, notably with the ongoing work to modularize the existing services, is almost 100 percent. However, compatibility is low.
- There is already a published document: [www.esri.com] so there is no need for the document to be adopted as an OGC Standard merely for interoperability with the ESRI implementation.
- The document, as a new, separate effort, repeats mistakes which were made and since solved by the other services.
- The document focuses on the past (notably with backwards compatibility and use of only GET/POST) not on the future.
- The document needs a comprehensive editorial review and substantial rewriting for clarity.
A conclusion
Both simple answers are bad.
A simple acceptance of the standard would introduce a new set of 'OGC approved' open services. The OGC approval might enable governments to buy a XXXX-new-name-here-XXXX solution instead of a W*S or a S*S solution. The path forwards towards harmonizing the services is unclear. Fixing this document in addition to fixing the W*S services will be a pain.
Simply rejecting the solution would be bad for the OGC. It would place the OGC in the position of picking winners and losers in the standards business. It would mean that the OGC is stuck on the project of fixing the W*S standards to meet some nebulous future functionality without having any path to get there. It would discourage innovation and progress.
Is there any third way?
Well, actually, there is a different way of thinking of the issue. Overall, there appears to be a shared desire for an integrated suite of geospatial services, originally focused on a simple data model, built on the exchange of well defined resources in simple formats including JSON, accessible and usable using the core HTTP verbs, and discoverable through following HTML links and patterns of URL paths. The hope is that such a suite can be designed based on the best expertise of the OGC, can be widely supported by the community, and can be implemented and tested by multiple groups. Neither the proposed document, nor the current services meet this vision. So the work, ultimately, is on improving all the services at the OGC, first to modularize them, then to enable simple implementations, and finally to link those implementations into a functional suite. Since this is the work that is already happening, perhaps the vote is an unfortunate distraction and the productive way forward is merely to redouble the efforts to create the next versions of the standards.
Issues with the document
Beyond the controversy described above, there are issues with the Geoservices REST API document itself. Even if the standard deserves support, these issues could be considered blockers to the adoption of the current, May 2013, document.
The critique is incomplete because it quickly falls into a full editorial review of the text, something which takes a lot of time and effort and is beyond the scope and intent of this Open Letter.
The critique can be found at: [wiki.osgeo.org] .
Note that some of these critiques hold the document to OGC's current, standards writing guidelines. The OGC has been striving to develop better standards so new standards must meet higher requirements than past standards. The lack of clarity in the proposed document is not substantially worse than many published standards but ought to be resolved in new standards.
Further ConcernsTechnical Concerns
- see this discussion for detailed arguments why OGC WCS is superior to the "GeoServices REST API" Part 6. It concludes:
In summary, the ESRI "Geoservice REST API" Imaging part is at a technological level where WCS departed from some 5 years ago.Inconciseness of the specification at large will make it difficult for third parties to come up with interoperable implementations. The components making up the ESRI "Geoservice REST API" provide natural blocks assignable to the matching SWGs. As for Part 6 of the ESRI "Geoservice REST API", if to become a standard it needs to be discussed in the WCS.SWG for harmonization, clarification, and improvement.
Methodological Concerns
- The Geoservices REST API can not be amended (other than editorial changes in the specification document), because of a requirement for backward compatibility with the ESRI implementation. This has limited improvements in this version of the candidate specification.
Further Reading
Please add links to referenced documents, related news stories or blog posts here.
- Call for comments on GeoServices REST API: [www.opengeospatial.org]
- Responses from the Standards Working Group to the comments received from the public during the public Request for Comments (RFC): File:OGC 12-642 GeoServices REST API - RFC Comments Response.pdf
- Responses from the Standards Working Group to the reasons given by the organizations voting _no_ during the adoption vote: File:OGC 13-031r1 GeoServices REST API - Response to no votes r1.pdf
- Email archive of OSGeo discussions about GeoServices REST API: [lists.osgeo.org]
- Adrian Custer's summary of technical issues (and original source of some content in this letter): [lists.osgeo.org]
- "Is OGC Loosing its way?", letter to OGC Voters, from OGC Interoperability Movement Team Leaders, [lists.osgeo.org]
6:21
Markus Neteler: FOSS4G-CEE 2013: Program published!
sur Planet OSGeo

Join us at FOSS4G Central and Eastern Europe (FOSS4G-CEE) 2013 from 16th - 20th June, National Library of Romania, Bucharest, Romania.

You will meet well known Keynote Speakers (random order): Jeff McKenna, Paul C. Smits, Jáchym Čepický, Schuyler Erle, Maria Antonia Brovelli, Dirk Frigne, Markus Neteler, Alyssa Wright, and Radu Puchiu.

Check the long list of Practical Workshops and Oral Presentations at: [2013.foss4g-cee.org]
Check out for the additional Code Sprint, the Open GeoData Hackathon, and the Open Data Side Event.

How to arrive? See [2013.foss4g-cee.org]
4:57
Edmar Moretti: Uso de estilos na interface Google Maps do i3Geo
sur Planet OSGeo

Aqui vão algumas imagens que mostram o resultado da aplicação de estilos nos mapas do i3Geo que utilizam a API do Google Maps.
O código que possibilita isso está disponível na versão 4.7 do i3Geo, mas apenas na versão atual do SVN, ou seja, por enquanto para utilizá-lo é necessário fazer o "update" ou o "checkout" do código do i3Geo diretamente do SVN.
Os estilos pré-configurados são os mesmos que podem ser vistos aqui: [maps-api-tt.appspot.com]
4:52
Eduardo Kanegae: Capturando coordenadas de um ponto com o Google Maps
sur Planet OSGeo

Já que o Google Maps vem aí com uma nova versão, não custa nada explorar um pouco a versão atual para realizar uma tarefa muito simples: "como capturar as coordenadas de um determinado ponto no Google Maps?" More »
16 mai 2013
21:45
Micha Silver: Get your phone GPS data into a GIS format
sur Planet OSGeo

Nearly every new phone or tablet these days comes GPS enabled. And you can choose any of a slew of apps to capture GPS waypoints and tracks. But how do you get these data into a GIS system? Several apps save the GPS data into an sqlite database, so using Spatialite to convert the locations to spatial layers is a piece of cake.

I tried using, for example, GPSEssentials, an Android app with all the bells and whistles. I’m not endorsing any one location app but this one (like some others) stores all its data into sqlite files. So I plugged my phone into a USB socket and copied the “waypoints” file from the gpsessentials folder over to my computer. Then I renamed the file to add the popular *.sqlite extension, and opened it in Spatialite_gui. For our purposes there are three tables of interest: Waypoint, Track, and TrackElement. The Waypoint table contains, of course, the waypoints with Longitude and Latitude coordinates, along with altitude, description, etc. The Track table is a list of tracks, and the TrackElement table is a crumb trail of Longitude/latitude values for each location along each of the tracks.
To transform these tables into true spatial layers, for use in GIS, you must first make the sqlite DB spatial. So:

SELECT InitSpatialMetaData();

Now we can use the Longitude/Latitude values in the waypoints table to create actual geometries. First call the AddGeometryColumn function:

SELECT AddGeometryColumn('Waypoint','geometry',4326,'POINT','XY'); UPDATE Waypoints SET geometry = MakePoint(longitude, latitude, 4326);

and Waypoint becomes a point layer ready to be opened in QGIS, for example, or exported to a shapefile.
But what about the tracks? Here we need an additional step. We make the Track and TrackElement tables spatial, then use the TrackElements to create LINESTRING features in Track geometry column:

SELECT AddGeometryColumn('Track','geometry',4326,'LINESTRING','XY'); SELECT AddGeometryColumn('TrackElement','geometry',4326,'POINT','XY'); UPDATE TrackElement SET geometry = MakePoint(longitude, latitude, 4326);

and now do the update on the Track table:

UPDATE Track SET geometry = (SELECT MakeLine(te.geometry) FROM TrackElement as te WHERE te.trackID = Track._id GROUP BY te.trackID)

and you’re done. The Track table is now a true line feature, and can be exported as a shapefile, etc. The column names above are as they appear in the sqlite tables created by this particular app, so you might have to replace some of the ingredients. But the recipe should be similar. So get out your spatial mixing bowl, and your phone becomes a handy GIS tool.
18:20
Sean Gillies: Getting back into OpenStreetMap
sur Planet OSGeo

The new OSM editor is a pleasure to use and I've been inspired to fix up my neighborhood a bit. It was cool to see these historic homes (designated Fort Collins landmarks, in fact) pop up in MapBox just minutes after I submitted them.

Google Maps, on the other hand, has no historic homes and a rather outdated and (sadly) never to be realized development proposal in the neighborhood. Fixing Google's map for free is not high on my list of priorities.

Next, I'd like to finally get some Pleiades-related data into the OpenHistoricalMap sandbox.
14:53
Slashgeo (FOSS Articles): OpenGeo Completes $3 Million Series A Financing and Launches as Independent Open Source Software Company
sur Planet OSGeo

New York, NY, May 15, 2013 — OpenGeo, the creators of the OpenGeo Suite, the world’s leading open source geospatial software platform, announced a $3 million Series A investment from Vanedge Capital of Vancouver, British Columbia. Simultaneous with the funding event, the company has spun out from its incubator parent, OpenPlans, and is boosting OpenGeo’s product and customer-support initiatives.

"We are thrilled to be working with Vanedge.” said Eddie Pickle, OpenGeo CEO. “The Vanedge team understands the huge opportunity in the geospatial software space. Their investment is very timely given the tremendous demand for open source, Spatial IT solutions among government and commercial enterprises worldwide."

The OpenGeo Suite is widely used for managing and sharing spatial data. OpenGeo has led the industry shift toward flexible, interoperable geospatial software infrastructures and will use this Series A funding to further enhance its industry-leading product and training offerings and reach a broader array of customers.

Moe Kermani, partner at Vanedge Capital, noted, "OpenGeo has developed an impressive customer roster who are using its product offerings in mission-critical software applications. The paradigm shift toward web and mobile geospatial services is well underway and is permanently altering the Spatial IT landscape. We believe this shift heavily favors open source and the OpenGeo Suite, which is ideally situated to become the de facto geospatial platform."

The Vanedge-led investment enables OpenGeo to complete its separation from tech incubator OpenPlans, which founded OpenGeo in 2002. "We are proud that our incubation with OpenPlans has been so successful," noted Chris Holmes, OpenGeo’s founder. "We look forward to growing our contributions to open source communities as a dedicated open source geospatial software company."

About Vanedge Capital

Vanedge Capital is a Vancouver, B.C. based venture capital fund focused on investments in interactive entertainment and digital media businesses. The fund managers have extensive experience and relationships in this sector and have built and led world-class companies in video games, computer animation and enterprise software, among others. For more information, visit www.vanedgecapital.com.

About OpenGeo

OpenGeo is the world leader for commercial open source geospatial software. Our global customer base uses the OpenGeo Suite, a complete open source geospatial web services stack, to deploy solutions for web mapping, transportation, telecommunications, open government and a huge range of other solutions. The OpenGeo Suite provides the best, continually updated geo web services platform along with maintenance agreements that include support and training. These agreements provide our customers with superior value and the growing functionality of continually enhanced open source geospatial software.

OpenGeo supports open source communities by employing key developers of PostGIS, GeoServer, and OpenLayers. We are committed to the ideals of open source and aim to bring the best practices of open source software to organizations around the world.

Media Contact

David Dubovsky
OpenGeo
+1 917-388-9077
media@opengeo.org
Google Plus One
8:17
gvSIG Team: gvSIG 2.0: Crear bibliotecas de símbolos (III)
sur Planet OSGeo
En anteriores posts de la serie de simbología hemos visto como crear una biblioteca de símbolos a partir de un conjunto de imágenes, realizando algunos ejemplos como el caso de las bibliotecas Google y OSM.

En algunos casos nos puede interesar realizar nuestra biblioteca de símbolos a partir de un fuente. Ya sea para tener como símbolos ciertas letras, números o caracteres especiales como en casos de fuentes que contienen símbolos gráficos.

Como ejemplo vamos a utilizar una fuente con símbolos de animales que hemos encontrado.

Una vez descargada e instalada en el sistema vamos a pasar a convertirla a imágenes. Para ello vamos a utilizar Inkscape, un software libre de edición vectorial al que ya hemos hecho referencia en alguna ocasión.

Para instalar una fuente sólo debemos abrirla con el visor de tipografías de nuestro sistema operativo y pulsar el botón “Instalar”.Una vez instalada ya nos aparece como parte de las fuentes disponibles en Inkscape. Añadimos texto y, por ejemplo, al escribir “ABCDEFGHI” nos aparece algo similar a:

Con dos sencillos pasos vamos a convertir esos caracteres en imágenes individuales y son:
- Trayecto/Objeto a trayecto: convierte el carácter a imágen.
- Objeto/Desagrupar: genera una imagen individual para cada carácter.
Ahora simplemente seleccionaremos cada uno de ellos y lo guardaremos como archivo individual, mediante la opción: “Archivo/Nuevo”, dando un tamaño al documento que sea similar al de nuestras imágenes. Cortamos y pegamos a este nuevo documento la imagen (por ejemplo la primera de ellas, el caimán) y con “Objeto/Alinear y distribuir” la centramos. La guardamos con un nombre reconocible (Caiman.svg). Hecho.

Para tener un símbolo distinto cuando esté seleccionado, lo pintamos de amarillo y lo “Guardamos como” con el mismo nombre acabado en “_sel”.

Ya podemos repetir esta acción con cuantos símbolos queramos importar. A partir de aquí ya sólo debemos usar el importador de símbolos de gvSIG y tendremos nuestra nueva biblioteca de símbolos disponible en gvSIG.

Filed under: gvSIG Desktop, spanish Tagged: gvSIG 2.0
6:20
Cameron Shorter: Starting build cycle for OSGeo-Live 7.0
sur Planet OSGeo

We are starting the build cycle for the 7.0 OSGeo-Live DVD/USB/VM which will be released in September 2013, ready for the global FOSS4G conference in Nottingham, UK. We would like to hear from anyone wishing to add new projects to the live DVD, anyone wishing to extend or add extra translations, or anyone who has ideas on how we should shape the upcoming release.
Also, could all projects please reply to us with which stable version of their software should be included in this release.
Key Milestones17 Jun 2013 All new applications installed, most old applications updated15 Jul 2013 Feature Freeze (all apps updated)05 Aug 2013 User Acceptance Test (all apps installed and working)26 Aug 2013 Final ISO sent to printers
... full schedule
OSGeoLive 7.0-alpha1 released
We have released the first alpha version of OSGeo-Live, which includes an update from Xubuntu 12.04 to 12.04.2 along with updated versions of applications from UbuntuGIS repository. Feel free to start testing your applications in the latest release. Download Alpha 1
About OSGeo-Live
The OSGeo Live demo DVD/VM/USB is an Xubuntu based distribution of Geospatial Open Source Software, available via a Live DVD, Virtual Machine and USB. You can use it to try a wide variety of open source geospatial software without installing anything.
15 mai 2013
20:10
OpenGeo Blog: OpenGeo Emerges
sur Planet OSGeo

This week OpenGeo took an exciting and important step forward as an organization. We’ve taken on investment and spun out from OpenPlans, our long time parent organization, to establish ourselves as an independent company. Our growth and this successful step out on our own are the result of our amazing team and the success of open source geospatial software that we’ve been working on for over ten years.

Vanedge Capital, a Vancouver-based venture capital firm, led the Series A round of investment that made this possible. We are truly excited to begin a partnership with Vanedge, an innovative fund led by partners who know how to grow and manage software technology companies.

This investment provides the capital we need to meet our objectives and continue to develop innovative technologies. If you’re a regular reader of this blog or have seen us lately at conferences or events, you know about the ambitious projects we’ve been working on: through-the-web-processing, breaking out of the GIS work-flow with Spatial IT, geospatial web-analytics and distributed versioning for geospatial – to name a few. This type of development requires not just the strong technical skills and forward-looking leadership that our team has, but it also requires resources, which Vanedge’s investment provides.

This investment also allows us to achieve our long-planned separation from OpenPlans, which founded and incubated us. We are grateful for the support and vision of OpenPlans over the years. And, since OpenPlans remains an investor in our new company, we’re looking forward to our continued partnership with them.

Our mission remains the same: to build the highest quality software for location and mapping, available to all. This investment gives us a stronger base of resources to support the open source communities we work with. We remain committed to the open source principles of collaboration, transparency, and freedom. We’ll be doing even more to develop the best geospatial tools while supporting the open source communities and our customers alike.

Look for more from us about the future of Spatial IT and how we can help you get there.

Find out more about this important step forward and please contact us if you have any questions.
18:48
MGCOT: MOOC – Alterações climáticas: o contexto das experiências de vida
sur Planet OSGeo

Os MOOC – Massive Open Online Course são cursos on-line, de acesso livre. Partem do princípio que o conhecimento é gratuito, os diplomas é que têm de ser pagos, caso o aluno queira ser avaliado por um professor.

O primeiro em língua portuguesa é sobre o contexto das experiências de vida das alterações climáticas, começou esta semana, e é lecionado pela Universidade Aberta. Teve mil inscritos.

Podem consultar aqui os conteúdos: http://imooc.uab.pt/imoocac13_guest
11:48
gvSIG Team: gvSIG 2.0: “Google” symbols library
sur Planet OSGeo

In the previous posts of the “gvSIG 2.0: Create symbol libraries” (1 and 2) series, we have seen how to create a new symbol library, through gvSIG, starting from a set of images and, then, create a deliverable package making possible to share the library with other users.

In gvSIG Association we are working on a set of interesting libraries and we want to make them available for the whole users community. All of them have been created from symbols with public domain license.

Today we announce the availability of one of these libraries that we think is going to strongly support all those users producing maps and thematic cartography with gvSIG. It is a “G symbols” library providing users with a set of symbols similar to the ones that are used in Google maps applications.

We are going to see how this library has been created so that users can exploit it as example to create their own libraries.

For point symbols (markers) we have started from the symbols collection produced by Nicolas Mollet, called “Map Icons Collection”. An excellent collection of categorized symbols, that can be as well downloaded in PNG format with different styles (classic, iOS, light,…). In this case we have selected the default style.

One of the most interesting aspect offered by “Map Icons Collection” is the possibility to define the colour of the downloaded symbols. We are going to use this option to later download, in yellow, the symbols (if you prefer that your symbols have a different colour, you just have to define it by this tool). Remember that if you want that a symbol changes when related geometry is selected, two different options can be used: define it manually-one by one- or perform the change automatically. When you load a set of symbols, for each loaded symbol, in presence of another symbol with the same name but with the suffix “_sel”, gvSIG will recognize it as the adopted symbol when selected.

In order not to be obliged to rename one by one all the downloaded symbols in yellow, we can use a files massive renaming tool (we have used pyRenamer, available for Linux and making possible to add the suffix “_sel” to the entire set of .png files in yellow). With a software as pyRenamer we can perform also action such as transform all the files name first letter in capital, delete strings that do not give useful information …and remember that the file name is the one adopted by the symbol in gvSIG.

Downloaded and categorized icons, after having been treated by pyRenamer, will look like as follow:

Now it is only needed to use the gvSIG symbols importer as we saw in a previous post and we will have our point symbols.

If we want to have also symbols for lines and polygons, similar to those that can be found in Google Maps, the RGB combination of such symbols can be found out through any image editor, such GIMP, and used to replicate them in gvSIG.Now only the creation of the package has to be done according to the already described procedure.

This package is already available from the addons manager (by selecting the URL http://downloads.gvsig.org/download/gvsig-desktop/ and looking for “Categories/simbology”) or download the package directly from here (gvspkg).

NB: When using point symbols you have to remember that, by default, no “y” offset is applied thus, if you want that the symbol will be over the geometrical point, symbol properties have to be edited adding an “y” offset with a value equal to the half of symbol size (in our case, since the symbol has a default size of 32, an offset of 16 will be used).

Filed under: english, gvSIG Desktop, training
14 mai 2013
21:35
Slashgeo (FOSS Articles): Bringing Esri to Open Source and Open Standards
sur Planet OSGeo

Chris Holmes shares a pretty insightful and informative letter in an entry named 'Opening Esri'. Esri's closer relationship with open source started with providing code on GitHub last September and even up to last February's official entry named going open source with Esri.

From the Chris Holmes entry: "So I wanted to give to Esri a measurable roadmap of actions to take that would signal to me a real commitment to ‘open’. [...] Each piece of Esri technology ideally could be used stand alone with other pieces. Stated another way, there should be no lock-in of anything that users create – even their cartography rules. [...] it is a business risk, since it opens up more potential competition. But it’s also a big business opportunity if done right. And reaches beyond mere business to being a real force for good in the world, becoming a truly loved company, with lots of friends."

Google Plus One
18:50
Jackie Ng: The lab experiment is evolving
sur Planet OSGeo

And no, I am not trying to build a new MapGuide viewer. :)
This new feature just makes such as task dead simple
13:48
Chris Holmes: Opening Esri
sur Planet OSGeo
So I’ve been meaning to write a post on this ever since I had a great talk with Andrew Turner, who recently joined Esri. He was expressing a good bit of optimism over Esri’s willingness to embrace ‘open’. My worry is that they would embrace the language of open, but not actually do the key things that would make a real open ecosystem. It’s easy to take enough action to convince more naive decision makers of their intentions, like esri.github.io, which looks like lots of open source projects, but is mostly code samples and api examples that are useless without pieces of closed software. So I wanted to give to Esri a measurable roadmap of actions to take that would signal to me a real commitment to ‘open’.

That was a couple months ago, but then life got in the way, as tends to happen with lots of planned blog posts. But in the meantime there’s been a fascinating flare-up around the GeoServices REST specification in the OGC (most conversation is behind OGC walls, but see open letters and lengthy discussion on OSGeo). And it similarly makes me want to address ‘Esri’ as an entity. The individuals matter less, I believe that most of them want to do the right thing. But the corporation as a whole takes action in the world, and that big picture matters more than what individuals within are trying to do. So here goes:
Dear Esri, I imagine you’ve been pretty confused and flummoxed by all the push back to the GeoServices REST specification. It is a pretty solid piece of technology, and theoretically is a great step towards opening up Esri more – putting previously proprietary interfaces in to an open standard. The key thing to understand though is that unfortunately very few people in this industry trust you. I am actually fairly unique in that I give you a whole lot more benefit of the doubt than most. In my life I try as hard as I can to only judge people based on their direct interactions with me, not on whatever people say about them. And though you aren’t exactly a person I do still try to judge in the same way. And I personally have never had a truly bad interaction with you. But amazingly just about everyone that I’ve encountered in the broader geospatial industry has. When I bring up that I’ve never been mistreated by you they have the utmost confidence that I inevitably will. I have always been fascinated by this, as I believe it goes far beyond ‘typical competition’, which is one thing people at Esri have told me – something like ‘they’re just jealous’. The amount of venom that otherwise totally decent people will throw out is incredible, and it makes it hard for me to not judge harshly, when so many people whose judgement I trust absolutely have felt really screwed in the past by you. Multiple times. In really unpleasant and unexpected ways. And it’s not just competitors, but partners and clients. So the fundamental point that needs making with regards to GeoServices REST was articulated well by one of my allies: ‘everyone in the OGC membership is objecting to the REST API because they believe ESRI to be fundamentally conniving and untrustworthy.’ He believes that if the REST interface had been proposed by anyone else then there wouldn’t be a problem – it would likely be an approved OGC standard by now. But people believe it’s a ‘cynical business play by an untrustworthy, well resourced, and predatory business interest.’ I have overall had a relatively positive take on the GeoServices REST API, because I don’t (yet?) believe you to be fundamentally conniving and untrustworthy. You’ve done an amazing amount good for this industry, but I do think you’ve just lost your way a bit. I imagine you think that putting this great interface in to OGC is a great step in the right direction, and it is, but unfortunately it’s too much too fast. It’s as if the schoolyard bully is suddenly super nice to you – you wonder what’s up his sleeve, how he’s going to screw you this time. But I believe there’s a path forward, to building up people’s trust so that something like GeoServices REST could be accepted in OGC. It just has to be slower and more incremental. This list is just what I can think of right now. There is a fundamental principle at work though, which is moving towards an architecture that encourages people to mix and match Esri components with other technology. Not merely implementing open standards to check the box, but building for hybrid environments: QGIS exporting to or editing ArcGIS Server, ArcGIS Desktop doing the same to GeoServer, TileMill styling a file geodatabase and publishing to ArcGIS Online, ArcGIS Desktop styling and publishing to Google Maps Engine or CartoDB, etc, etc. Each piece of Esri technology ideally could be used stand alone with other pieces. Stated another way, there should be no lock-in of anything that users create – even their cartography rules. Anything that is created with Esri software should be able to be liberated without extreme pain, in line with the Data Liberation Front (though I think the google maps engine and earth enterprise teams also need som help from them, they too deserve a similar letter). I realize this is a big leap, since it is not the absolutely most efficient way to solve the needs of most of your customers, since most of them use only your software. And it is a business risk, since it opens up more potential competition. But it’s also a big business opportunity if done right. And reaches beyond mere business to being a real force for good in the world, becoming a truly loved company, with lots of friends. This list is roughly ordered by easier wins first, and so later ones should probably build on them. If these actions are taken I will start to defend you to my friends a lot more.
- Enable W*S services by default in ArcGIS Server. You’ve done a pretty great job of doing CITE certified implementations. But as the docs show they are not enabled by default, though GeoServices REST and KML are.
- Make GeoJSON an output option for the ArcGIS Server REST implementation (and get the clients all reading it). And then get it in the next GeoServices REST specification version.
- Publish the file formats of file geodatabase. The open API was a really great step, and indeed goes 80% of the way. But many libraries would like to not have to depend on it. We all know the format itself is likely an embarrassing mess, but everyone will forgive, as we’ve all written embarrassing code and formats.
- Help the coming GeoPackage be the next generation of file geodatabases. Help it evolve to be the main way Esri software moves data between one another. Your team has been great on it so far, but the key step is to make it a top level format not just in mobile but also on ArcGIS Desktop (reading and writing it, like a shapefile), Server and Online (as an output format and upload configuration format for both). And I’m hoping your team can join our plug-fest this week, to get to 3 real implementations before version 1.0 of the specification.
- Stop the marketing posts about how open you are. Open is action and conversation, not a press release or a case study. No need to talk about how we’ll be ‘surprised’ by what you open in the future. Just start opening a lot and let others do the posts for you, and count on that reaching your customers if you’re doing it well.
- Openly publish the .lyr file format (and any other formats that define cartography and internal data structures for maps). This is probably an internal format that isn’t pretty, but opening it would enable a lot of cool hybrid architectures.
- Support CartoCSS as an alternative to .lyr file, and collaborate around advancing it as an open standard to ideally make it the next generation .lyr file. This likely will include a number of vendor extensions as your rendering capabilities are beyond most everyone else. But we can all collaborate on a core. Supporting SLD in desktop would also be great, but we can also just look to the future.
- Move WFS and GML support out of ‘data interoperability‘ extension and in to core format support
- Bring support for WFS-T to ArcGIS Desktop, so people can use their desktop to directly edit a WFS-T server. The server side support in ArcGIS Server is great, but the client software also needs to implement the open standards for real interoperability. I think a similar thing might be needed for Desktop to edit directly with GeoServices REST, though maybe that is there now.
- Support WFS-T in Javascript API and iOS SDK (and I guess flex and silverlight, since you tend to try to have all toolkits the same).
- Become a true open source citizen. This is another large topic, and as is my tendency I’m already going on too long. So perhaps I will detail it more in another post. I have limited the above to mostly standards, but embracing open source can take you even further. But it is much more about contributing to existing open source libraries and building a real community of outside contributors on your projects, not just releasing lots of code on github. Karl Fogel wrote an excellent book on the subject. You are making some progress on this, but it is just a smidgen if you are actually serious about opening up. I will give props for the flex api, though my cynical friends would say it’s the easiest one to open source as it is dying. So please, do continue to surprise us on the open source front, you just don’t need to talk about it a bunch.
So I believe that doing a majority of these will send a strong signal that Esri is truly changing to be more open and that the submission of the GSR spec and putting code on github is more than a marketing move. My personal recommendation for you on the GeoServices REST specification is to back down from the OGC standardization for now. Instead work to evolve the spec in the open, and try again in a year or two. I don’t think any argument is going to win over those against it, only real action will. And continuing to try to force it through will only hurt our global community. I do believe there has been really great progress made on the spec through the OGC process, and the resulting document has a much higher chance of being implemented by others. Perhaps we could make it an ‘incubating’ OGC standard, that evolves with OGC process, but does not yet get the marketing stamp. The key to me is to encourage real implementations of it, and continue to advance Esri’s implementation as well, but in dialog with other implementers. Everyone can now start with the latest version, but without the backwards compatibility requirement. Call it GeoServices REST 1.0 – it can be a standard that improved from the OGC process though needs more ‘incubation’ before it deserves the full stamp of interoperability. And aim for 1.1 or 2.0 to happen outside the OGC, and once there are 3 solid implementations all influencing its future then resubmit to OGC. One thing that I think could help a lot is to publish and work on the spec on github, where people can more easily contribute. Take a more agile process to improving it, that doesn’t depend on a huge contentious vote and lots of OGC process. And when the trust has grown all around submit it to be an official OGC document. I believe this would also be one of the best signals to the wider world of Esri’s commitment to open, to dialog publicly and then iteratively address the concerns of all objectors in a collaborative process. If done right it will fly through the OGC process the next time, or else by then we will all be working together towards the next generation APIs that combine the best of GeoServices REST and W*S, while cutting down complexity. It will be difficult, but will ensure that the geospatial industry remains relevant as the whole world becomes geospatial. So let’s all be as open as we can to figure out how to get there together. Sincerely Chris Holmes
(Written as a private citizen, who cares about our collective future and believes geospatial has a higher role to play than just an ‘industry’. Views expressed here do not reflect my employer or any other organizations I am associated with)
9:26
Gis-Lab: Сервис архивации и контроля портала открытых данных
sur Planet OSGeo

Государственные структуры зажаты постоянным финансовым кризисом, катастрофическим недостатком кадров и остаток созидательного потенциала подавляется неэффективными бюрократическими процессами. Вместе эти проблемы затрудняют освоение не только новых технологий, но и элементарных основы работы с данными. Все это выражается в значительном отставании от других стран в области раскрытия важных наборов данных под незапретительными лицензиями и в удобном виде, особенно в отдельных областях.

Тем не менее, случается, что государственная структура создает что-то полезное в области открытых данных и положительным и единственным существенным примером является Портал открытых данных г. Москва. Поскольку данные открыты, общественность может взять на себя часть функций, с которыми, по ее мнению, неважно справляется сам портал.

Например взять и организовать удобный сервис архивации данных и оповещений об изменениях.

Прочитать описание/Обсудить

Немного примеров:

Обновление: Аттракционная техника с механическим приводом, установленная… (498), записи -21 tinyurl.com/cor7u56

— DataMosRu Updates (@datamosru) 12 мая 2013 г.

Данные удалены? Объекты капитального ремонта улично-дорожной сети… (625)tinyurl.com/buxaq2g

— DataMosRu Updates (@datamosru) 12 мая 2013 г.
7:53
gvSIG Team: gvSIG 2.0: Mapas temáticos I
sur Planet OSGeo
Derivado del proyecto gvSIG Batoví hay disponibles dos extensiones que añaden funcionalidad muy interesante para los usuarios de gvSIG 2.0.

Estas dos extensiones están disponibles a través del administrador de complementos y se denominan:
- Thematic Maps generator
- Thematic Maps viewer document
Mediante ambas vamos a poder trabajar con un nuevo tipo de documento, al que hemos denominado “Mapa temático”.

Los “mapas temáticos” son, realmente, un nuevo tipo de Vista en la que el usuario tiene opciones básicas de consulta. En su origen, el proyecto gvSIG Batoví, se buscaba que los alumnos de educación primaria y secundaria pudieran fácilmente compartir mapas temáticos, eliminando las herramientas complejas de la interfaz de gvSIG. Y, también, pueden ser una base perfecta para generar visores cartográficos.

Vamos a poder generar “mapas temáticos” a partir de cualquier “Vista” y convertir ese “mapa temático” en un paquete instalable desde cualquier gvSIG (con el administrador de complementos). Es decir, vamos a poder empaquetar una “Vista” con sus leyendas, capas, etiquetado…y distribuirla a otros usuarios de gvSIG.

Sin duda el mejor método para compartir información son las Infraestructuras de Datos Espaciales, pero a pequeña escala, para intercambio sencillo de información, vamos a encontrar muchas posibilidades con los “mapas temáticos”.

En primer lugar vamos a ver mediante el siguiente vídeo como instalar la aplicación:

Si reiniciamos nuestro gvSIG veremos que ya nos aparece el nuevo tipo de documento.

En este primer post veremos como generar un “mapa temático” a partir de una “Vista”.

Vamos a crear nuestro primer mapa temático a partir de una “Vista” con una serie de capas cargadas y configuradas. Es tan sencillo como desde la propia “Vista” ir al menú “Mapa temático” y seleccionar “Crear a partir de Vista”. Nos aparecerá una ventana en la que indicaremos las características de nuestro mapa.

Pulsamos “Siguiente” y podemos validar que todo está correcto. Si no hemos rellenado alguno de los campos anteriores nos lanzará un aviso, aunque es a modo informativo y nos permite crear igualmente nuestro “mapa temático”.

El campo descripción lo podemos utilizar también para indicar si hemos utilizado alguna biblioteca de símbolos particular, de cara a que los usuarios con los que lo vamos a compartir el mapa sepan que deben tener instalada dicha biblioteca de símbolos para visualizarlo correctamente.

Pulsamos en “Finalizar” y automáticamente gvSIG creará el nuevo documento:

En el siguiente post veremos como generar un paquete y compartir el “mapa temático” con otros usuarios.

Filed under: gvSIG Desktop, spanish Tagged: gvSIG 2.0
13 mai 2013
19:19
Martin Davis: Beautiful cartography using OpenJUMP
sur Planet OSGeo

An OpenJUMP user just posted some really nice cartographic maps made using a combination of OpenJUMP, Inkscape, GRASS, and GIMP.
Roman Empire - Physical Map
Roman Empire - Political Map

He gives OJ the following glowing endorsement:
I find Open JUMP to be the most vector-friendly open source GIS software. The preparation of the datasets (rivers, lakes, sea, roads, borders) was really [a] piece of cake...
It's great to see the small but dedicated OpenJUMP community steadily adding new features and improving the software quality. 10 years after it was launched, OpenJUMP continues to be the "Little Open-Source GIS that Can".
15:36
Edmar Moretti: Movimento da OSGEO que pretende barrar a proposta da ESRI
sur Planet OSGeo

Olá

Gostaria de divulgar e pedir o apoio ao movimento da OSGEO que pretende barrar a proposta da ESRI quanto aos padrões OGC.

Link: [wiki.osgeo.org]

Tradução de alguns trechos (não deixe de ler o original, que é mais completo):

"
Nós, abaixo assinados, consideramos que a aprovação da "Geoservices API REST" como um padrão OGC, terá impactos negativos sobre a interoperabilidade da indústria geoespacial.

Nós recomendamos fortemente que a proposta de "Geoservices API REST", de maio de 2013, seja rejeitada como um padrão OGC.
"

"
A aprovação do documento como um padrão OGC é controversa para uma grande variedade de razões, incluindo:

    - processo pelo qual o documento foi desenvolvido, que impede a participação das várias partes interessadas,    - a funcionalidade dos novos serviços duplicam o dos serviços já existentes padronizados pelo OGC tais como WMS, WFS, WCS, e WPS,
    - a adição de um novo conjunto de serviços com base em novos padrões de URL e novos formatos JSON é visto como a duplicação de esforços de outros grupos de trabalho, trazendo idéias semelhantes às atualizações dos serviços OGC existentes,
    - a re-introdução de questões previamente resolvidas, que é visto como "não construir sobre os conhecimentos e experiências existentes",
    - o uso dos esquemas JSON particulares que são vistos como tendo pouca aceitação na indústria e são incompatíveis com outros esquemas utilizados, e
    - a falta de diversidade de implementação que é pensado para dar vantagem comercial ao fornecedor de uma implementação já completa .
Estas questões têm impactos potenciais sobre o uso de 'Padrões Abertos " por governos e empresas, relativa à interoperabilidade do software, sobre os custos para os usuários e desenvolvedores de padrões de software, no entendimento de ' Padrões Abertos ' pelo público em geral, e, possivelmente, sobre a reputação da OGC como um campeão de interoperabilidade.
Em particular, há uma preocupação por parte de alguns de que a adoção do padrão provavelmente vai resultar em uma combinação das seguintes opções:

    O custo para os desenvolvedores de aplicativos, integradores de sistemas, testadores e patrocinadores para suportar todos os padrões OGC relevantes será aumentado substancialmente.
    Consequentemente, as organizações e / ou aplicativos podem optar por apoiar apenas um padrão, ou apenas apoiar um padrão totalmente.
    Patrocinadores (como os governos), que exigem o cumprimento de padrões OGC irão descobrir que as aplicações não se comunicam em conjunto, devido a aplicações que suportam diferentes padrões OGC que essencialmente fazem a mesma coisa.
    Isto irá resultar em uma diminuição da importância do OGC, como o selo de aprovação "padrões OGC".

    Depois de um tempo, a fim de resolver problemas de interoperabilidade, uma organização ou programa provavelmente vai tomar a iniciativa de impor um padrão como o preferido para todas as agências seguirem. Até à data, o OGC tem proporcionado esta liderança.

    Um padrão, tendo proeminência sobre o outro provavelmente vai levar o outro a se tornar obsoleto, resultando em muitos sistemas OGC se tornando sistemas legados no processo. Isto deve ser considerado um resultado indesejável para uma organização de padrões.
Em resposta (réplica) a estas questões, os autores do documento API REST Geoservices afirmaram que :

    - processo do OGC foi completamente seguido,
    - a especificação realmente é RESTful e não define uma API,
    - nome, devido à controvérsia, pode ser aberta para a modificação
    - OGC não proíbe a duplicação de funcionalidade do serviço,
    - formato JSON existe e funciona, e
    - há implementações alternativas para alguns destes serviços.
Os autores também salientam que a existência de uma grande base de usuários mostra que o serviço é útil, e que a padronização dos serviços no OGC pode incentivar novas implementações.
"

--

http://edmarmoretti.com.br
http://www.i3geo.com.br
Skype, Gtalk: edmar.moretti
11:54
gvSIG Team: La nouvelle version finale de gvSIG disponible : gvSIG 2.0
sur Planet OSGeo
L’Association gvSIG annonce l’édition de gvSIG 2.0 version finale. La principale nouveauté de cette version est son architecture. La manière dont gvSIG gère les sources de données a été revue, avec l’objectif d’améliorer la fiabilité et la modularité, au bénéfice des utilisateurs et des programmeurs. Cela permet en plus une maintenance plus facile, et facilite l’évolution des technologies. Par conséquent, il y a eu un investissement réalisé sur le futur, avec le but de ne pas limiter les évolutions technologiques et d’établir les bases pour une évolution rapide.
Cependant, cette nouvelle version de gvSIG Desktop inclus une série de nouveaux éléments:
- Nouvel installeur pour des installations typiques ou adaptées.
- Manager d’Add-ons qui permet d’installer de nouvelles extensions et d’adapter gvSIG.
- Quelques changements dans l’interface de gestion de données, tels que:
  - import/export de fichiers
  - opérations sur les tables
  - nouveau calque
- Chargement de calques amélioré
- WMTS (Web Map Tiled Service) accepté
- Cache pour données Raster
- Interface de géotraitement unifiée
- Import de symboles, création de bibliothèques de symboles facilitée
- Export de symboles, qui permettent de partager facilement des bibliothèques complètes de symboles.
- Canevas de Scripting (langages: Jython, Groovy et Javascript).
Bien que ce soit la dernière version de gvSIG, il faut prendre en compte que c’est une version complètement nouvelle de gvSIG, dans laquelle certaines fonctions de gvSIG 1.12 ne sont pas incluses. Ces fonctionnalités seront incluses dans des mises à jour à venir, au rythme de leur migration à la nouvelle architecture. Les principales fonctionnalités par encore incluses sont les suivantes:
- Géoréférencement
- Légende par symboles proportionels, symboles gradués, densité de points, quantités par catégories et par expression.
- Extensions: Analyses de réseau et 3D
De la même manière, il existe plusieurs projets basés sur cette nouvelle architecture, qui permettront d’ajouter de nouvelles fonctionnalités et améliorations directement dans gvSIG 2.0 dans les prochains mois.

Il doit également être pris en compte que le niveau de stabilité de cette version n’est pas aussi élevé que nous l’aurions souhaité, et le fait de la considérer comme une version finale est une manière de la proposer officiellement à l’usage de la communauté, et de prévoir de nouveaux développement sur celle-ci.

Nous vous encourageons donc à tester et à nous envouyer toute érreur trouvée, dans le but de les fixer dans les mises à jour à suivre. Les erreurs connues de la version 2.0 sont consultables à cette page.

Pour télécharger cette version, plusieurs miroirs seront disponibles dans quelques jours.

Nous espérons que vous apprécierez les nouvelles fonctions de cette version et que vous nous aiderez à l’améliorer.

Filed under: community, french, gvSIG Desktop
10:07
GeoServer Team: New GeoServer community on Google+
sur Planet OSGeo

Being social and sharing with others is one of the keystones of a open source community.

Traditionally open source communities thrive on mailing lists and IRC channels, however it’s not news that many people prefer other medias for sharing thoughts, experiences, and asking for help. For example, people with an interest in GeoServer are already active on Twitter and StackExchange.

Simone recently created a new Google+ GeoServer community, adding one more choice to the mix: [https:]]

If you like mailing lists do not worry, the GeoServer users mailing list will still be the primary and official mean to get support (and we very much suggest you to hang there too), the Google+ community is just an alternate mean of communication that some of us might want to try out.

So, if have an interest in GeoServer and your preferred media is Google+ hop on, if we see there is enough interest we might start doing hangouts and public presentations to leverage this social platform extra features.
9:38
gvSIG Team: gvSIG 2.0: Scripting, exploit your gvSIG (II). Creating a buffer
sur Planet OSGeo
In some previous posts we’ve seen how to create an easy script on gvSIG 2.0.

Now we show a video about how to implement a script to create a polygon shapefile that is obtained after applying a buffer to the geometries of a point layer. The buffer distance is obtained from a field of the point layer.

The steps to follow the script are:
- We get the input layer.
- We create the data definition (Schema) of the new layer.
- We get the creation data of the new layer.
- We create the new layer.
- We scan the features of the input layer (points).
- We create the new geometries.
- We add the new feature to the new layer.
- We finish the editing of the new layer.
- We release the group of features of the input layer
The source code with comments is:
```
from gvsig import *

def main():
  #We get the active layer
  layer = currentLayer()

  #We create the data definition
  schema = createSchema(layer.getSchema())
  schema.modify()

  #We get the projection
  crs = currentProject().getProjectionCode()

  #We define the path where the new layer
  ruta = "/home/victor/carto/influencia.shp"

  #We create the layer
  newLayer = createShape(
    schema,
    ruta,
    CRS = crs,
    geometryType = SURFACE
  )

  #We get the features of the input layer
  features = layer.features()

  #We scan all the features 
  for feature in features:

    # We get the value of the buffer
    influencia = feature.get("Influencia")

    # We create the geometry coming of the buffer on the feature geometry
    geom = feature.geometry().buffer(influencia)

    # We get the values of the input feature attributes
    values = feature.getValues()

    # We add the new geometry in the new layer
    values["GEOMETRY"] = geom
    newLayer.append(values)

  # We finish the editing of the new layer saving changes
  newLayer.commit()

  # We release the group of features of the input layer
  features.dispose()
```
You have to take into account that it’s necessary to use gvSIG 2.0 Final version and the Scripting Framework extension to work without problems. Although the view must have an active layer and this layer has to have a double type field called Influencia. And better, you can modify the script to adapt it to your data.

We hope you enjoyed it.

Filed under: english, gvSIG Desktop, scripting
2:00
Cameron Shorter: Last chance to reject "Geoservices REST API" standard
sur Planet OSGeo

Taxonomy upgrade extras: OSGeo ogc
Next Wednesday, the OSGeo Board will deliver an Open Letter to the OGC and OGC voting members, with multiple signatures, demonstrating the large number of people concerned about the negative consequences associated with making the "Geoservices REST API" an OGC standard.
The "GeoServices REST API" was initially developed by ESRI and implemented on the ArcGIS Server platform before going through the OGC process. It significantly overlaps with OGC's existing W*S services, but isn't based upon these existing standards. Consequently, we have grave concerns that the two competing sets of standards, which essentially cover the same use cases, will have far reaching, detrimental impacts on interoperability, complexity, and costs within the spatial industry, including being bad for Geospatial Open Source software.
Many people, including leaders of OSGeo and related communities, have already signed this letter. Thank you. If you agree that "Geoservices REST API" will be bad for OSGeo and/or the greater spatial community, then please help us deliver this concern to OGC voters before they vote. Add your signature to the Open Letter before we deliver it on Wednesday 15 May 2013, and forward this message onto other OSGeo communities. (I notice that messages from this thread are being forwarded to the Spanish OSGeo email list. Thank you.)
If you are looking for a deep analysis of the issues, I suggest reading the open letter which is now draft complete: [wiki.osgeo.org] .
12 mai 2013
23:08
Tim Sutton: How to do some quasi 3d cartographic effects in QGIS
sur Planet OSGeo

No words for this one, just pictures! Above: What we are trying to achieve… Above: Our symbol layers Above: The roof colour is data defined A shadow Layer And a highlight layer One other hint – don’t forget to enable symbol levels!
23:03
Jachym Cepicky: Invitation to new PyWPS development
sur Planet OSGeo
It has been a while, since we’ve touched code base of PyWPS properly. We were focused on fixing of reported issues, which were usually not that big. For most people it seemed, that PyWPS was just working silently somewhere at the server and doing it’s job.

But time has moved and some limitation of the PyWPS design have proved to be not-so-well. There is also new version of Python available (we started PyWPS when 2.2-2.4 were around), with new features. We tested new libraries (lxml for instance, I would like to see OWSLib more incorporated with next release of PyWPS).

Some concepts, which were introduced by PyWPS, were adopted by others (GRASS GIS integration, MapServer for output serving, and others), which is great. Also we were looking around, for some inspiration.

I think, time, when we should start to write the new PyWPS has come. We have already collected some ideas for the 4.x branch, especially:
1. Use Python 2.7 (for future 3.0 migration)
2. Try different interpreters of Python (pypy)
3. Easy parsing with lxml
4. Prepare for next WPS version
5. Change of the whole process concept? Probably only cosmetic changes, users do like the way, how they can script anything they want, in a way, they prefer.
6. And other ideas …
We have also learned something about unit tests, mod_python isn’t that sexy any more, using simple SQLite database for storing information about running processes, having possibility to pause/resume them etc. is also on the table.

By and large, it has all been said. I would like to invite you to join the development of brand new PyWPS (will be moved to geopython github once, it’s ready). I’ve already started, but I basically did only some basic directory structure + basic parsing of input request (POST and GET) is implemented for GetCapabilities and DescribeProcess request types. Nothing more.

I’ve started to go on using python unit testing from the beginning. I also started completely from scratch – the code has nothing in common with current 3.x branch of PyWPS. If you are interested in contribution, or if you have some ideas, what PyWPS should change, what it should preserve, what it should include, you are welcome to join the old mailing list.

I do not assume, we will be approaching too fast (I do not have too much time left over, I do assume, nobody has), but still, once started, it makes fun again to think about the project and it keeps me continuing. If we would finish it within year, I would be satisfied. So join us, it will be fun!
Share Tweet
11 mai 2013
4:09
Sean Gillies: A good day for the little format that could
sur Planet OSGeo

Today was a pretty good day for the GeoJSON format.

Josh Livni announced on Twitter that the Google Map Engine API had been published. The little format that could has a good role in the API.

Ed Summers blogged about wikigeo.js, a library that gives you a GeoJSON interface to Wikipedia API results. Ed is absolutely right about how usable and right for the web mapping software has become since younger web developers and designers have started to displace older earth science programmers like myself.

A good example of which is Tom MacWright's edit geojson app: draw a shape and copy the GeoJSON representation, paste some GeoJSON and render the shape.

The business of geospatial standardization may have hit a rough patch recently, but things aren't all bad. Developers are still finding ways to agree, share, and do good work.
10 mai 2013
23:03
Free and Open Source GIS Ramblings: QGIS Flickr Group
sur Planet OSGeo

The excitement about the upcoming 2.0 release is growing and to add some fuel to the fires, Mathieu founded the QGIS Flickr Group. Anyone can join and add their maps done with QGIS master.

I’m looking forward to seeing what you have come up with. Please note that this group is meant for maps only (therefore no screenshots of the application please).
18:04
Jackie Ng: MapGuide tidbits: Maximizing .net code reuse
sur Planet OSGeo
Code reuse is always a good thing. If you use the .net MapGuide API, you may want to consider some options that can enhance re-usability of your code.

For those who don't know, the MapGuide API is an extension of a common subset known as the Geospatial Platform API. AutoCAD Map3D extends this subset to integrate with AutoCAD Map3D, MapGuide extends this common subset to support web applications and mg-desktop extends this subset to give you a portable MapGuide environment for your desktop applications.

As you can see from the diagram there are key abstract classes in the Geospatial Platform API that are derived by the various implementations (bolded for emphasis). It just so happens that these classes are the key classes for working with maps and layers and the rest of the API through service classes.
By writing your .net code to work against the abstract classes in the Geospatial Platform API, you get to maximize its reuse against the various extensions of this common subset. For example, have your code:
- Work against MgMapBase instead of MgMap, MgdMap or AcMapMap
- Work against MgLayerBase instead of MgLayer, MgdLayer or AcMapLayer
- Work against MgResourceService instead of AcMapResourceService or MgdResourceService
You hopefully get the idea. Where possible, work against the abstract class instead of the concrete implementation.

Writing code this way makes the code more amenable to easy manual dependency injection, with your MapGuide, mg-desktop or AutoCAD Map3D specific code doing the actual injecting, but the dependency injectee not having to care because it works against the abstract class and not the concrete implementations, thus allowing this injectee code to be re-used anywhere that can provide a concrete implementation of the class.
Of course, each extension of the common subset has their own implementation quirks. AutoCAD Map3D has some, mg-desktop has some too. But if such quirks do not affect you, then this coding strategy is something to consider if you want to re-use such code beyond MapGuide web applications.
17:11
Jackie Ng: Another lab experiment
sur Planet OSGeo
14:24
gvSIG Team: OGC ¿OSRI Geospatial Consortium?
sur Planet OSGeo

Seguramente la mayoría de ustedes estará enterada de la propuesta por parte de ESRI para que su API de Geoservicios REST pase a ser un estándar OGC.

Aquí un documento promovido por Cameron Shorter donde argumenta el desacuerdo con esta propuesta y que va recibiendo adhesiones.

Esta situación ha abierto interesantes debates en diferentes listas, como por ejemplo en varios hilos de una lista de OSGEO y en la lista SIG de RedIris.

En el documento citado y en los debates de las listas se verán diversos argumentos en contra y a favor. Preocupaciones técnicas y comerciales del porqué un ESRI estándar pasa o no a ser un OGC estándar. Que si ya solapa con otros estándares y lo que habría que hacer es evolucionar los ya existentes para paliar sus deficiencias. Que si dónde vamos con un estándar cuya implementación de referencia viene soportada tan sólo por un software privativo. Que si realmente no es REST y son muchas sus deficiencias técnicas…

Por otra parte, ¿Que por qué ESRI no va a poder proponer que su implementación sea estándar? Que para eso paga, contribuye, financia OGC y está en su derecho. Esto recuerda eso de: ‘oiga, quien paga manda’. O que si ESRI realmente promueve los estándares porque está en OGC. Vamos, algo como que ESRI está en OGC para promover los estándares…aunque eso pudiera ir contra su modelo de negocio.

Pero por encima de todos estos argumentos, recordamos una presentación que ya tuvo lugar en el 2009 en la sesión 5 de las 5as jornadas internacionales de gvSIG en Valencia (España) donde hablando de los estándares, llevaba como título ¿Qué pasa cuando pones al zorro a cuidar del gallinero?

La tesis principal de esta ponencia es que una cosa es lo que venden las grandes empresas y otra la que practican.

ESRI nos vende que apuesta por lo estándares y por la interoperabilidad y que por eso financia OGC o el FOSS4G. Pero cualquiera que sepa algo de que va esto, conoce que el principal modelo de negocio de ESRI, sea directamente o a través de sus múltiples filiales, es la especulación con el conocimiento, sea en venta de licencias de software o en dificultar el acceso a la información a través de sus ‘estándares’.

¿Qué podemos esperar entonces? Prácticas que en absoluto son exclusivas de ESRI. Igual podemos hablar de Autodesk y el DWG o de Bentley y el DGN v8. ¿Recuerdan como se comportó ESRI con su librería ArcSDE? Desde luego, una práctica que muestra realmente lo que le preocupa la compatibilidad.

Así que ahora, de las grandes compañías cuyo modelo de negocio es el privativo, nos vamos a creer que han entrado en una lógica racionalista y sostenible y van a dejar de hacer el FUD sobre el software libre por las puertas traseras del poder y van a apoyar los estándares. Que van a dedicar recursos a unas organizaciones como OGC, potenciando los estándares aunque vayan en contra de sus intereses comerciales.

Claro, siempre olvido lo que ya escribimos aquí en una ocasión en el 2010, y es que el Arcgis is Open .

Por último, sobre la carta promovida por Cameron, indistintamente de que pueda haber un debate enriquecedor sobre ciertos matices de la misma, quiero agradecerle esa iniciativa.

Filed under: opinion, spanish
10:59
MGCOT: Sessões Temáticas 360º Ciência Descoberta
sur Planet OSGeo

Sessões temáticas 360º Ciência Descoberta
14 mai 2013 | 18:00 | Entrada livre

PROGRAMA
14 maio 2013 - Sessão temática no Auditório 3
Cartografia: do Mediterrâneo ao Mundo todo
Joaquim Alves Gaspar

15 maio 2013 – Auditório 2
Searching Nature in the American World: Bringing the Scientific Revolution to its Iberian Context
Antonio Barrera Osorio, Colgate University, EUA

21 maio 2013 – Sessão temática no Auditório 3
Instrumentos e Técnicas da Navegação antiga
José Manuel Malhão Pereira

Local – Fundação Calouste Gulbenkian

Mais informações: [www.gulbenkian.pt]
8:28
gvSIG Team: gvSIG 2.0: Biblioteca de símbolos “OSM”
sur Planet OSGeo

¿Hay alguien que todavía no sepa que es OSM (OpenStreetMap)? Por si hubiera algún despistado, OpenStreetMap es el proyecto colaborativo de referencia para crear mapas libres y editables a lo largo y ancho de todo el planeta.

Siguiendo los pasos definidos en la serie de post “gvSIG 2.0: Crear bibliotecas de símbolos” hemos creado una nueva biblioteca de símbolos para nuestro gvSIG a partir simbología relacionada con OSM. La disponibilidad de esta biblioteca se enmarca en nuestra idea de que los usuarios de gvSIG dispongan de un amplio y variado conjunto de bibliotecas de símbolos, instalables mediante el “Administrador de complementos”.

Veamos como hemos realizado esta biblioteca, de modo que sirva como un nuevo ejemplo a los usuarios para crearse las suyas propias.

Para los símbolos puntuales (marcadores) hemos partido de la colección de símbolos realizada por “SJJB Management” bajo licencia Creative Commons (CC-0) y denominada “SJJB SVG Map Icons”. Una excelente colección de símbolos por categorías que nos podemos descargar en formato SVG. Parte de estos iconos tienen su origen en el “US National Park Service Cartography” y otras fuentes de dominio público que pueden consultarse en la web de SJJB.

Como hemos comentado en post anteriores, el nombre que gvSIG da a cada símbolo es el nombre del fichero, por lo que hemos utilizado una herramienta de renombrado masivo de archivos para realizar esta tarea; en nuestro caso hemos utilizado pyRenamer, disponible para distribuciones Linux. Mediante Inkscape hemos generado los distintos símbolos de selección (coloreando de amarillo cada símbolo y añadiendo la terminación “_sel” al nombre del fichero).

Todo preparado para el importador de símbolos de gvSIG como vimos en un post anterior y de forma automática se crea la nueva biblioteca con el conjunto de símbolos puntuales importados. En este caso hemos decidido crear una serie de subcarpetas para clasificar el conjunto de símbolos.

Queríamos que esta biblioteca tuviera además símbolos líneales y polígonales similares a los que podemos encontrar en OSM. En el caso de que no hubiera documentación sobre la composición de los símbolos, mediante cualquier editor de imágenes, como GIMP, podemos averiguar el RGB de y crear unos similares en gvSIG.

Hemos generado tanto símbolos lineales:Como símbolos de relleno:Ya sólo nos queda crear el paquete tal y como explicamos en este post.

Este paquete lo tenéis disponible desde el administrador de complementos (seleccionando la URL [downloads.gvsig.org] y buscando por “Tipos/symbols”) o directamente descargándoos el paquete desde aquí.

Filed under: gvSIG Desktop, spanish Tagged: gvSIG 2.0
09 mai 2013
23:09
Geo-preneur: The OGC is Stuck in 1999
sur Planet OSGeo
All these new OGC standards are sadly designed like it is still 1999.

If you don’t like ramblings, then here is the TL;DR for you:

TL;DR OGC Standards should be written for the future, not the present nor the past

I have to get something out of my chest. Yes, it is triggered by the current discussions about accepting GeoServices REST API as an OGC standard.

The current focus of the discussion, at the core, is around the issue that the GeoServices REST API is perceived as a set of competing standards (i.e redundant to the WFS/WMS/WCS/etc specs) that don’t have an open (read open source) reference implementation that any organization can refer to when trying to implement the standard.

To me, this discussion is more about politics (which I do agree is a valid topic to discuss) than about the reality of the standards that do come out of the OGC lately.

Reading any of the documents from the OGC make me feel like I am listening to Prince (before!) 1999.

Seriously.
Standards should be written for the future – not the present
I remember several years back when HTML5 was the hot new thing. The standards were being worked on a lot, but most of the browsers did not support any of the features from HTML5. The table at caniuse.com (a place where you could go to see what HTML5 features were implemented by what browsers) were mostly red (i.e. not implemented).

Fast forward four years into the future, most of it is green. That is because those standards became adopted and the functionality that it brought to life makes everyone’s life better.

Designed in the past, adopted in the future. The way it should be.

Contrast this with the current set of standards that we have “up for comment” from the OGC right now…

Before you think that I am against the OGC, let me tell you that you could not be further from the truth. In most presentations that I have given in the last 6 years (at several conferences, some keynotes, and even my own GeoMeetups ) I have always dedicated slides and time to convince/teach people about the OGC and the importance of standards.

Yet, although I have several friends that do work in these standard bodies (I love you guys – you know who you are!), it still feels that there is an unnecessary amount of bureaucracy at the OGC that is truly killing innovation.

OGC is making “standards” that are outdated, unnecessarily overly-complicated, reference implementations that cannot be used as a reference (read below!), and a whole bunch of protocols that resemble what a protocol would have looked like in 1999. They completely ignore what we have learned in the last decade.

Let me give you some real examples.

- WFS, XML Datastores and queries:

XML Datastores were all the academic hype back in the day. Yet they never took off (with reason). The query language used by OGC (which is another OGC standard) assumes the underlying data store is XML. For those of you not familiar with what this actually means, it is more than a representation of something as text. It assumes you have an XML Infoset.

At the core, the OGC spec for Filters is just an attempt to represent SQL as something equivalent to an XPath expression to be used on the web (?!?).

Anybody that has ever tried implementing WFS will understand what this means. Basically, several months of development, to create a parser that grabs an xml document and turns it back into SQL. But to do it correctly, you don’t have to generate one SQL statement, but several ones. Why? Because the query language is so expressive, than in reality you should be able to create expressions that span multiple underlying tables (it assumes it is an XML Datastore after all) which basically makes you just really sad and go home depressed because it is unnecessarily complex.

I have an idea, why, instead of writing a client application that transforms my query into OGC filter speak, goes through a middleware that grabs the OGC filter speak and turns it back into SQL which then goes to my underlying database - instead - do I just not have one method (ExecuteSQL) and be done with it. Use SQL. Let’s just not reinvent a SQL. The CartoDB guys seem to have this right in their API . One tiny little api, you pass a string… it does a lot! You know how long it takes to implement something like this? Hours, not months. And you actually have more power than what is expressed by the OGC equivalent. Problem solved.

- XML/GML as a transport mechanism:

This is the mechanism of transport of choice for OGC standards. I have a two year old post about why I think this is far from ideal. Although there are some updates to be made to that answer, at the core, it still remains valid. If somebody tells you that the answer is to ‘gzip’ GML, then, they are wrong (a topic for a future post).

I am still baffled as to why do none of the standards, yet, refer to things like Protobuffers, MessagePack, Thrift, Avro - gosh - anything that we have learned to do better in the past decade!

Switching to any of these, or including them as serialization options would make all the implementations of these standards better/faster.

- “Reference Implementations” that cannot be referenced It is true that a “reference implementation” should be able to be, well, referenced. I cannot currently look at how the GeoServices REST reference implementation (I guess ArcGIS Server) is implemented internally, thus, the specification fails at having a valid reference implementation.

Does that mean that for a reference implementation to be useful it needs to be Open Source?

Maybe that is not enough.

Some people would argue that the reference implementations for the OGC GeoPackage spec, Spatialite, is arguably also not a good choice.

Why?

Because you cannot copy/paste or even create “derivative work” from it without also having to GPL/LGPL your work. Is looking at a reference implementation, seeing the internals, and copying how it works considered derivative work? Those are the type of questions that no developer wants to deal with, so IMHO, the OGC has the responsibility to pick reference implementation that in unencumbered by these issues. By picking Spatialite and a proprietary server (ArcGIS Server) as reference implementations to their respective specs, the OGC is showing that they are either 1) really clueless about these type of issues, or 2) don’t care. Either way, this is horrible.

- Websockets?

I wish! Where are the implementations that take advantage of full duplex communications? Server side push? Seriously, are we still assuming users are going to poll all the time and transfer state in every request? This is exactly why most real-time tracking implementations are done incorrectly. Why are we still stuck in a stateless architecture design? We can do server push now without Flash or Java (or Silverlight yikes!). Websockets exist. USE THEM.

I touched superficially around this topic in the last PyCon. The video is up if you are interested.

- [Https,] Authentication/authorization, security

I don’t even want to touch on authentication/authorization around all the OGC specs. OAuthv2, or even the first version of that are far better than what is expected of the current implementations of security. Most people rely on passing USERNAME/PASSWORD in the request. This is horrible.

But wait, I guess if I use [https] that means I am secure right? Hell no!

Look at this video from last year’s Blackhat (quite awesome actually) and then come back with a straight face and tell me this is fine.

** - SPDY** If you do not what SPDY is, then, you will definitely be surprised to tell you that all your [https] traffic to Google , Facebook and Twitter is not going over “traditional” SSL.

Yes, they use a special protocol called SPDY.

It is faster than traditional http (even though it is going over an encrypted channel!). Think about this for a sec.

Does the OGC use SPDY? Of course not. Does it make a difference? Check out this video of last year’s Google I/O about SPDY and you be the judge.

- Non-blocking servers.

The Mapbox guys get it. They use node.js for serving their tiles. Do you want to understand why this is a good thing? Check out this presentation by Ryan Dahl 3 years ago which gives an overview of why this is the case.

Anyway.

I can go on and ramble forever, but I want this to be more constructive.

**The discussion around OGC specs should be about what GIS is going to be like in 5 years in the future. **
- Why did the OGC not work with the W3C to push WebSQL through (now stalled)? Imagine spatial extensions in every browser on the client side?
- Why don’t we have a good spec about spatial replication, spatial changetsets, optimistic/pessimistic/long-transaction versioning, etc?
- Why don’t we have specs that take advantage of web stateful connections?
- Why don’t we have a spec for highly compressed geometries?
- Why don’t we have a spec that defines better editing capabilities? (hint: WFS-T is not enough for several editing workflows)
- Why don’t we have a spec that defines how to truly take advantage time-based datasets?
The list goes on.

Instead, the community as a whole is having long discussions analogous to the one about whether 3857, 3785 or 900913 was a better number for the Web Mercator definition.

Listen OGC, want to see a good standard definition? Check out MBTiles. Easy to implement, and to the point.

Want to change? Design/Define for the future - not for the present nor the past.
20:25
Slashgeo (FOSS Articles): Launch of the Open Source 'MapBox Earth' for iOS
sur Planet OSGeo

MapBox announced their open source iOS virtual globe named MapBox Earth.

From the announcement: "We just launched MapBox Earth, a free and open source iOS app that combines the power of a 3D globe with MapBox’s beautiful maps. It’s also a great starting point to build your own 3D mapping app - we’re cracking the 3D globe software market wide open by releasing the source code and building in the open. MapBox Earth is a universal app optimized for iPhone and iPad and it includes beautiful preloaded layers based off of MapBox Streets, MapBox Terrain, and MapBox Satellite. You can switch the map layer with a single tap and feel the maps right in your hands, in gorgeous and fast 3D."

We did mention some other open source virtual globes in the past months / years, such as Glob3 Mobile, the Godzi WebGL Globe, OpenWebGlobe, WebGL Earth, and there's even the Google open source 'WebGL Globe'.

Google Plus One
20:08
Slashgeo (FOSS Articles): OpenStreetMap Launches iD: All-new Easy Map Editor
sur Planet OSGeo

Two days ago the new open source iD editor we mentioned a few times has been officially launched, here's the official announcement OpenStreetMap launches all-new easy map editor and announces funding appeal.

From the announcement: "The new editor, codenamed ‘iD’, boasts an intuitive interface and clear walk-throughs that make editing much easier for new mappers. By lowering the barrier to contributions, we believe that more people can contribute their local knowledge to the map – the crucial factor that sets OSM apart from closed-source commercial maps. [...] The new iD editor is a pure HTML5 experience, using the cutting-edge D3 visualisation library. Behind the clear design and intuitive interface is a sophisticated back-end that automatically recommends the most popular ‘tagging’ conventions used by the OSM community."

Numerous sources discussed the new iD editor, you'll find more technical details on iD on the MapBox blog, MapBox built iD, including multiple links to media coverage. Slashdot also discussed two stories, OpenStreetMap Launches a New Easy To Use HTML5 Editor and OpenStreetMap Adds Easier Reporting of Map Problems.

Google Plus One
16:00
Nathan Woodrow: QGIS Map Flickr group
sur Planet OSGeo
Want to show of some the cool maps you have made using QGIS 1.9/2.0?

Mathieu has now setup a new Flickr group to collect and show of cool maps that have been made using the new features in the upcoming QGIS 2.0.

The group can be found at [www.flickr.com]

Here is one I uploaded a few days ago

and a cool one from Anita

Anyone can join and submit to the group.

There are just a few rules:
- No Screen shots of the application
- Only output from the composer or Save Image As..
- List data sources used
- List any new QGIS features used e.g blending, label buffers, etc
- Only post maps you are proud of or you would show your mother
A QGIS Map Book might be on the cards in the future so keep that in mind when uploading a map to the group.

Now go forth and make awesome maps!
11:27
Jorge Arévalo: Solving GDAL issues for gvSIG CE project
sur Planet OSGeo
Recently, I’ve been working for gvSIG CE project, thanks to the folks of geomati.co (I’m part of the team now!)

I was solving some GDAL related open cases (this, this and this). the aim is to get a functional and stable gvSIG CE 1.0 version. There are still a couple of cases to solve (this and this), but I think we’re pretty close.

I’d like to explain what I did to solve these cases.

Make gvSIG CE work with GDAL 1.9.x

This bug was hard to find but easy to fix. First, a 1-minute introduction to GDAL use in gvSIG CE.

gvSIG CE uses a JNI wrapper (based on GDAL 1.7.x GDAL packed JNI wrapper) to make C++ native calls to GDAL library. There are 2 important GDAL JNI wrapper classes involved in most GDAL operations:
- Gdal.java (it interacts with native C++ GDALDataset class)
- GdalRasterBand,java (it interacts with native C++ GDALRasterBand class)
Both classes inherit from the same base class: JNIBase. This class defines a function named baseSimpleFunctions that calls one of several native C functions, depending on an input parameter. But some of these native C functions are GDALDataset-based, and other are GDALRasterBand-based. I mean, the pointer passed to them doesn’t hold the same C structure (wrapping C++ object) in all cases.

And here was the thing. To actually read the raster data, the Java function GdalRasterBand::readRaster is called. This function checks the position and size of the region being accessed, comparing it with the raster dimensions. To check this, the C functions getRasterXSize and getRasterYSize are called. These functions expect a pointer to a GDALDataset C object, but the GdalRasterBand Java class provides a pointer to a GDALRasterBand C object. I had to replace those Dataset-based calls to RasterBand based calls, to match the underlying C structure.

Replace ECW and MrSID driver with GDAL

First, a few comments on these formats.

ECW stands for enhanced compression wavelet. This propietary format is a high-performance image-compression format designed specifically for geospatial imagery. It’s patented and owned by Intergraph. More information here.

Intergraph provides a license needed SDK for encoding data and a free SDK for reading. Since version 4.1, this free SDK is only available for Desktop development on Windows systems. There are promises to include Linux support since 5.0 version, but gvSIG CE doesn’t plan to support ECW and other proprietary formats. So, I worked with the last known version working on Linux systems too. This is 3.3.

About MrSID, it stands for multiresolution seamless image database. It’s a proprietary format too, owned by LizardTech. As happens with ECW, there’s a free SDK to read MrSID files. It can be downloaded from here (MrSID SDK, under Tools & Utilities. Free register required). And as happens with ECW too, gvSIG CE won’t directly support this format. So, it delegates in GDAL.

In both cases, we’ll need to compile GDAL with the proper support. So, I had to download and compile MrSID and ECW libraries and build GDAL using –with-ecw and –with-mrsid options.

As there is a JNI wrapper for GDAL, there are JNI wrappers for ECW and MrSID. The goal was: get rid of them, and give GDAL credentials to handle these formats. Four steps involved here:
1. Compile GDAL with ECW and MrSID support, as said
2. Tell GDAL to take care of those formats for reading (class GdalDriver)
3. Unregister ECW and MrSID drivers from gvSIG CE raster library (libRaster)
4. Delete ECW and MrSID wrappers and native code.
Once done, you have gvSIG CE using GDAL 1.9.2 to read raster data, including ECW, JP2, MrSID and Lidar files (previously managed by ECW and MrSID drivers).
10:33
gvSIG CE: gvSIG CE using GDAL 1.9.2 to read raster data, including ECW, JP2, MrSID and Lidar files
sur Planet OSGeo

Recently, I've been working for gvSIG CE project, thanks to the folks of geomati.co(I'm part of the teamnow!). I was solving some GDAL related open cases (this, thisand this). the aim is to get a functional and stable gvSIG CE 1.0 version. There are still a couple of cases to solve (thisand this), but I think we're pretty close. I'd like to explain what I did to solve these cases.Make gvSIG CE work with GDAL 1.9.xThis bug was hard to find but easy to fix. First, a 1-minute introduction to GDAL use in gvSIG CE. gvSIG CE uses a JNI wrapper (based on GDAL 1.7.x GDAL packed JNI wrapper) to make C++ native calls to GDAL library. There are 2 important GDAL JNI wrapper classes involved in most GDAL operations:Gdal.java(it interacts with native C++ GDALDataset class)GdalRasterBand,java(it interacts with native C++ GDALRasterBand class)
Both classes inherit from the same base class: JNIBase. This class defines a function named baseSimpleFunctions that calls one of several native C functions, depending on an input parameter. But some of these native C functions are GDALDataset-based, and other are GDALRasterBand-based. I mean, the pointer passed to them doesn't hold the same C structure (wrapping C++ object) in all cases.And here was the thing. To actually read the raster data, the Java function GdalRasterBand::readRasteris called. This function checks the position and size of the region being accessed, comparing it with the raster dimensions. To check this, the C functions getRasterXSizeand getRasterYSize are called. These functions expect a pointer to a GDALDataset C object, but the GdalRasterBandJava class provides a pointer to a GDALRasterBand C object. I had to replace those Dataset-based calls to RasterBand based calls, to match the underlying C structure.Replace ECW and MrSID driver with GDALFirst, a few comments on these formats. ECW stands for enhanced compression wavelet. This propietary format is a high-performance image-compression format designed specifically for geospatial imagery. It's patented and owned by Intergraph. More information here.Intergraph provides a license needed SDK for encoding data and a free SDK for reading. Since version 4.1, this free SDK is only available for Desktop development on Windows systems. There are promisesto include Linux support since 5.0 version, but gvSIG CE doesn't plan to support ECW and other proprietary formats. So, I worked with the last known version working on Linux systems too. This is 3.3.About MrSID, it stands for multiresolution seamless image database. It's a proprietary format too, owned by LizardTech. As happens with ECW, there's a free SDK to read MrSID files. It can be downloaded from here(MrSID SDK, under Tools & Utilities. Free register required). And as happens with ECW too, gvSIG CE won't directly support this format. So, it delegates in GDAL.In both cases, we'll need to compile GDAL with the proper support. So, I had to download and compile MrSID and ECW libraries and build GDAL using --with-ecw and --with-mrsid options.As there is a JNI wrapper for GDAL, there are JNI wrappers for ECW and MrSID. The goal was: get rid of them, and give GDAL credentials to handle these formats. Four steps involved here:- Compile GDAL with ECW and MrSID support, as said- Tell GDAL to take care of those formats for reading (class GdalDriver)- Unregister ECW and MrSID drivers from gvSIG CE raster library (libRaster)- Delete ECW and MrSID wrappers and native code. Once done, you have gvSIG CE using GDAL 1.9.2 to read raster data, including ECW, JP2, MrSID and Lidar files (previously managed by ECW and MrSID drivers).Jorge Arevalo
10:14
gvSIG Team: gvSIG 2.0: Mirrors for downloads
sur Planet OSGeo

One of the most important characteristics of the gvSIG Desktop 2.0 version is the Add-ons Manager, from which the different packages (extensions, add-ons…, and translation files later) can be installed directly from the application. This version is totally oriented to this, it won’t be necessary to download the extensions independently and install them from gvSIG after that. For this reason, it become necessary to have several download servers available, several mirrors for downloading the packages.

Until now, the download servers have been provided by the gis-lab.info Russian Community, the gvSIG Russian Community, LAPIG (Laboratório de Processamento de Imagens e Geoprocessamento, Universidade Federal de Goiás, Brazil), the i3Geo Project (Edmar Moretti, Brazil), Geocuba (Cuba), ELOGeo (E-learning for Open Geospatial Community, University of Nottingham, United Kingdom), and the Open Source Geospatial Foundation (OSGeo).

This new infrastructure will allow to download the packages of the different extensions, add-ons, etc., from the Add-ons Manager in gvSIG (Tools->Addons Manager menu). For this reason the different servers URL have been included in a pull-down menu at the home window.

In addition, it will allow to download the application binaries (the All-included version) from the downloads table at the gvSIG website, where the user will be able to choose the server which they will be downloaded from.

From the gvSIG Project we want to thank all the people and entities that have provided these download servers.

Filed under: english, gvSIG Desktop
8:13
BostonGIS: Chopping rasters with gdal_translate
sur Planet OSGeo

We had this big raster that we needed to chop up into tiles and only extract a portion of for load into PostGIS. raster2pgsql doesn't currently have an option to pull just a portion of a raster and also we don't have the windows raster2pgsql compiled with MrSID support. Luckily GDAL commandline gdal_translate has this switch that allows you to specify a chunk of a raster to grab based on a projected or unprojected box window. We wanted to grab just that portion that is part of boston and chunk it into bite size pieces. What we needed was a grid generator similar to what we described a while back in Map Dicing and other stuff that would chop our neighborhood into bite sized tiles we could then use to generate the relevant gdal_translate command. Instead of using temp tables and all that stuff, we decided to try with the ST_Tile raster function. Creating an empty raster and then tiling it.
Note the repurposing: Creating a raster with no bands to accomplish a task that has nothing to do with rasters, so that we can then apply it to something to do with rasters. Gridding is a surprisingly common step in a lot of spatial processing workflows.

Here is the SQL to do it and we'll explain in a separate article in more detail.

In a nutshell, we're using PostGIS raster technology (ST_Tile function introduced in PostGIS 2.1) that we demonstrated in Waiting for PostGIS 2.1 ST_Tile to create a grid because PostGIS geometry doesn't have cool gridding function like SpatiaLite has :). SpatialLite tesselation. Perhaps in PostGIS 2.2 we'll see some of these SpatiaLite niceties. However ST_Tile does the trick fairly nicely and quickly. For this example took under 600 ms to generate 1524 rows of GDAL commands.

Continue reading "Chopping rasters with gdal_translate"
2:50
Geo-preneur: UbuntuGIS - GIS on Linux
sur Planet OSGeo

I sometimes get surprised to find out that some people don’t know how easy is to get GIS packages on Ubuntu. UbuntuGIS is really one of the easiest ways to get up and running. You will notice that there are two repos.

UbuntuGIS “Stable” which has really old packages. You most likely don’t want that.

UbuntuGIS “Unstable” which is really not unstable at all. It just has newer packages. You do want that!

To get it working in your Ubuntu system add the ubuntugis-unstable repo:

sudo add-apt-repository ppa:ubuntugis/ubuntugis-unstable -y sudo apt-get update sudo apt-get upgrade

Now you can install all kinds of cool packages.

sudo apt-get install postgis gdal qgis

Is an example of how to get gdal, postgis and qgis ready to go.

Enjoy.
08 mai 2013
15:13
MGCOT: Visualização 3D em desktop gvSIG e QGIS
sur Planet OSGeo

Atualmente desktops SIG (Free and Open Source) como o GRASS (nVIZ), gvSIG (extensao 3D) e QGIS (plugin GLobe) integram a componente de visualização 3D de informação geográfica.

De entre as soluções citadas para visualização 3D o gvSIG é uma solução muito friendly. O inconveniente é o facto da funcionalidade 3D apenas estar incluída numa versão mais antiga do gvSIG (1.11). A nova versão do gvSIG (2.0) irá só mais tarde integrar a extensão 3D. Por enquanto, resta aguardar e continuar a usar a versão antiga do gvsig para quem queira usar esta funcionalidade.

Instruções para instalar o gvSIG + 3D no Linux:

1) Download
- Versão gvSIG 1.11 [www.gvsig.org] .
- Extensão 3D [www.gvsig.org] .

2) Instalar
No sistema operativo Linux (Ubuntu 12.10) é conveniente instalar a versão BN17 (beta) da extensão 3D, pois não tem tantas restrições relativamente aos drivers. As outras versões não funcionaram.
$ chmod +x gvSIG-1_11-1305-final-lin-i586-withjre-j1_5.bin
$ .\gvSIG-1_11-1305-final-lin-i586-withjre-j1_5.bin
$ chmod +x gvSIG-1_10-3D-0_2_0-17-beta-lin-i586-j1_5.bin
$ .\gvSIG-1_10-3D-0_2_0-17-beta-lin-i586-j1_5.bin
Run from terminal ~/gvSIG_1.11.0_final/bin$ sh gvSIG.sh
Aqui está!

Uma outra solução é usar o nVIZ do GRASS a partir do QGIS. A implementação do plugin GRASS no QGIS veio melhorar em muito o acesso à visualização quer a 2D quer a 3D da informação produzida no GRASS. Num primeiro contacto o NVIZ é ligeiramente “menos friendly” na visualização da informação, mas permite manipular outros aspectos como a iluminação de um modelo 3D. Acrescento ainda que no QGIS 1.9 denota-se alguma instabilidade no nVIZ aquando da adição de informação vector produzida no GRASS7.
13:35
Simone Giannecchini: GeoSolutions participates at the GeoSpatial World Forum 2013 in Rotterdam
sur Planet OSGeo

Dear All,
we'd like to announce that GeoSolutions will be present at the GeoSpatial World Forum Conference which will be held in Rotterdam between the 13th amd 16th of May 2013.

GeoSolutions will be represented by its founder and director Ing. Simone Giannecchini as well as by its Director of Biz Dev & Sales Dott. Eleonora Fontana, In particular Simone Giannecchini will speak on the 16th during the Open Source session as well as during the session focused on SME and INSPIRE.

If you are at the conference and you'd like to network with us to talk about we could build a collaboration leveraging on our Open Source products, drop us a few lines!

The GeoSolutions team,
11:30
MGCOT: Visualizar dados dos Censos 2011 com o QGIS
sur Planet OSGeo

[object Window]
via Visualizar dados dos Censos 2011 com o QGIS.
7:53
gvSIG Team: gvSIG 2.0: Biblioteca de símbolos “Google”
sur Planet OSGeo

En post anteriores de la serie “gvSIG 2.0: Crear bibliotecas de símbolos” (1 y 2) hemos visto como generar una nueva biblioteca de símbolos para nuestro gvSIG a partir de un conjunto de imágenes y, posteriormente, generar un paquete distribuible que nos permita compartir esa biblioteca con otros usuarios.

Desde la Asociación gvSIG estamos trabajando en un conjunto de bibliotecas que consideramos de interés para que estén disponibles para toda la comunidad de usuarios. Todas ellas realizadas a partir de símbolos con licencias de dominio público.

Hoy anunciamos la disponibilidad de una de estas biblioteca y que consideramos va a suponer un buen aporte a todos aquellos que diseñan mapas y realizan cartografía temática con gvSIG. Se trata de una biblioteca “G symbols” que pretende que dispongamos de un conjunto de símbolos similares a los que se manejan en las aplicaciones de mapas de Google.

Veamos como hemos realizado esta biblioteca, de modo que sirva de ejemplo a los usuarios para crearse las suyas propias.

Para los símbolos puntuales (marcadores) hemos partido de la colección de símbolos realizada por Nicolas Mollet, denominada “Map Icons Collection”. Una excelente colección de símbolos por categorías, que además nos podemos descargar en formato PNG con diferentes estilos (classic, iOS, light,…). En nuestro caso hemos seleccionado el estilo por defecto.

Uno de los aspectos más interesantes que nos ofrece “Map Icons Collection” es la posibilidad de definir el color de los símbolos que vamos a descargar. Esta opción la vamos a utilizar para descargar una segunda vez los símbolos, está vez en color amarillo (si quisierais que vuestros símbolos seleccionados tuvieran otro color, no tenéis más que definirlo con esta herramienta). Recordad que si queremos que un símbolo cambie cuando se selecciona la geometría que lo adapta tenemos dos opciones: definirlo manualmente -uno a uno- o bien realizarlo de forma automática. Al importar un conjunto de símbolos, gvSIG para cada símbolo importado, si existe otro con un nombre similar y sufijo “_sel”, interpreta que es el símbolo que adoptará cuando esté seleccionado.

Para no tener que renombrar uno a uno los símbolos descargados de color amarillo podemos utilizar una herramienta de renombrado masivo de archivos (en nuestro caso hemos utilizado pyRenamer, disponible para distribuciones Linux y que nos permite añadir el sufijo “_sel” a todo el conjunto de ficheros .png con color amarillo). Con un software como pyRenamer podemos además realizar acciones como que todos los archivos comiencen por mayúscula, eliminar cadenas que no nos aportan información,…y recordemos que el nombre del fichero es el que adoptará el símbolo en gvSIG.

Los iconos descargados y clasificados por categorías, una vez tratados con pyRenamer, tendrían un aspecto similar al siguiente:

Ahora ya sólo tenemos que utilizar el importador de símbolos de gvSIG como vimos en un post anterior y tendremos nuestros símbolos puntuales.

Queremos que esta biblioteca tenga además símbolos líneales y polígonales similares a los que podemos encontrar en Google Maps. Mediante cualquier editor de imágenes, como GIMP, podemos averiguar el RGB de estos símbolos y crear unos similares en gvSIG.

Ya sólo nos queda crear el paquete tal y como explicamos.

Este paquete lo tenéis disponible desde el administrador de complementos (seleccionando la URL [downloads.gvsig.org] y buscando por “Tipos/symbols”) o directamente descargándoos el paquete (gvspkg) desde aquí.

Nota: Cuando uséis los símbolos puntuales tened en cuenta que por defecto no tienen aplicado un offset en “y”, por lo que si queréis que la viñeta aparezca encima del punto geometríco debemos editar las propiedades del símbolo y añadir un offset en “y” de la mitad del tamaño del símbolo (en nuestro caso, como a los símbolos les hemos dado por defecto el tamaño de 32, utilizaremos un offset de 16).

Filed under: gvSIG Desktop, spanish Tagged: gvSIG 2.0
1:52
Sean Gillies: Upcoming
sur Planet OSGeo

On the 22nd of May, I will be arriving in Minneapolis for the North American edition of the FOSS4G conference and on the next day I will be presenting a talk entitled GeoJSON is Spectacularly Wrong. I had also submitted a Python GIS talk and was surprised and concerned when both were accepted because there's no way I could pull off two. I'd enjoy talking about Python programming a little more, but it looks like the community is slightly more interested in GeoJSON. I hope that I didn't chose the wrong topic. Thursday night I'll be at the fancy shindig and because open source GIS events always need more dudes I will be bringing my brother. Friday I'll be sticking around to hack and catch up with what's going on in the field. It's been a long time since I've been to one of these conferences. Maybe I can share my Python 3 porting experience or offer a "show me your Python script and I'll show you how to make it measurably better/faster, or your money back" service. Yes, like in 2003, I'm going to a Yo la Tengo show one of the nights (here in Colorado, which is why I'm arriving late). No, unlike in 2003 I'm not driving.

The following week I'm going to be at Drew University in Madison, NJ, for the second part of ISAW and Drew's Linked Ancient World Data Institute. Just between you and me, I'm a bit burned out on talking about linked data; it's long past time to just start producing and using linked data to get stuff done. I believe that's what we're going to try to do at Drew this year.
07 mai 2013
22:35
gisky: Should the "Geoservices REST API" become an OGC standard?
sur Planet OSGeo
ESRI recently submitted their ESRI server REST standards to the OGC. Currently, the voting members have to decide whether they accept the proposal or not. As one of the contributors to the OSGEO-Live dvd, Cameron Shorter invited me to the discussion at Osgeo discuss list.
This discussion comes at an interesting time. Just a few weeks ago I did a session on geospatial web services in my company. The actual reason that we covered this topic is that there are two interesting (and diverting) trends happening at the same time:
1. The current OGC standards are finally taking off. Ever since our governement started serving their large-scale reference maps as publicly available WMS services, I see them being used by many of our customers
  At the same time, I managed finding interesting data sets using CSW services for the first time, and the fact that view and metaservices have to be provided for INSPIRE III themes by the end of the year will probably mean that the shift to using services is finally taking off.
2. On the other hand RESTful GIS services have started popping up everywhere. ESRI's proposed Geoservices REST API is one, GeoREST is another one which I've enjoyed using.
Actually my first thoughts when using ESRI's api was a sense of relief: I really enjoyed using these services. The fact that I can just tinker using an URL rather than having to use a special SOAP client was nice. My productivity as a programmer increased enormously. I couldn't figure out why anybody would want to use SOAP-like services (without going in a semantic discussion).

So you would expect that I'd support the Geoservices REST API as an OGC standard? Well, no. Quite a large number of valid points have been raised: the name is bad, the existing reference implementation is commercial without available sources, ...
But I'd like to raise a different point: there are too many different services involved: the proposed standard comes in 8 different parts, all covering services which in my opinion unrelated.
```
  12-054r2    GeoServices REST API - Part 1: Core
  12-055r2    GeoServices REST API - Part 2: Catalog
  12-056r2    GeoServices REST API - Part 3: Map Service
  12-057r2    GeoServices REST API - Part 4: Feature Service
  12-058r2    GeoServices REST API - Part 5: Geometry Service
  12-059r2    GeoServices REST API - Part 6: Image Service
  12-060r2    GeoServices REST API - Part 7: Geoprocessing Service
  12-061r2    GeoServices REST API - Part 8: Geocoding Service
```
This is the opposite of the unix philosophy: have one tool for the job. This is what in my opinion services should be about: have one service for every job, so one standard for every service.
One tool for every job? Image source

I don't understand why a good feature service should also provide geocoding, maps or any other service. Yet these small tools will not be able to comply to the standard because they can provide only one service.
So my proposal would be: break up the proposal. Check where new standards may be useful or where RESTFul implementations of existing services (and we already have a long list) are more appropriate. The services provided by ESRI prove that such an implementation really boosts productivity.
And actually while doing this, perhaps we should immediately consider using binary data where appropriate. I started off by saying that web services are finally being used. I did not mention WFS. This is logical. Nobody likes WFS. It is too slow. If WMS would contain an xml record for every pixels with an attribute for every color nobody would use it either. No, WMS sends a binary image. Why isn't WFS doing the same and sending vector data in a binary form?
9:12
gvSIG Team: gvSIG 2.0: Add-ons manager
sur Planet OSGeo
One of the most new and useful functionalities in gvSIG 2.0 would be the Add-ons manager, even though a first version was already available in gvSIG 1.12. The main advantages of the new Add-ons manager are:
- Add-ons can be updated without waiting for the upcoming release of gvSIG.
- Installation of gvSIG can be customized.
- Add-ons such as symbols, languages and script can be easily shared.
Before explaining how this tool works, it is important to know the exact version of the downloaded gvSIG software, because depending on the version, different add-on options can be selected:
- Standard version. It contains the packages of the default setup plus a reduced number of add-ons. It corresponds to the release “All included version” of the download table.
- Online version. It contains basic and minimum gvSIG setup without any add-ons. To finalize the setup, an internet connection is needed. It corresponds to the release “with no extra software” of the download table.
The Add-ons manager allows to modify the default setup by adding or deleting the default add-ons and to install or update add-ons later on. In this article we are going to explain how this tool works, assuming that gvSIG has already been installed.

The Add-ons manager is available in the menu Tools/Add-ons manager in gvSIG 2.0. When launched, a dialog window appears, showing three options as shown in the following picture:
- Standard installation (install addons contained in the gvSIG standard distribution)
- Installation from file (install addons contained in a .gvspki or .gvspks file)
- Installation from URL (install addons from a remote repository)
Details for each option:

Standard installation

This option is available only if gvSIG has been setup from standard distribution, which allows to install only the add-ons already included; usually the most diffuse and stable add-ons are included. This option, thus, is the safer one because it should guarantee add-ons without fatal errors.

No internet connection is needed during the installation procedure.

Installation from file

The most evident advantage of this distribution is the possibility to install shared add-ons with another person even if they are not in the official gvSIG repository. It is useful even if you want to install an official add-on downloaded previously and individually. All the available add-ons for gvSIG version 2.0 can be browsed through this link [1].

Installation from URL

Through this option it is possible to view all the add-ons available in different repositories. The URL suggested by default refers to the repository of the installed distribution, containing all the release compatible add-ons, including the ones in development.

Other URLs relate to generic official repository mirrors of the installed release (gvSIG 2.0 in this case) through which all the add-ons compatible with all the distributions of a given release we can download.

This option is suggested if you want to test add-ons under development since all add-ons are shown without any indication of the state of development. For the same reason it is not indicated to install to many add-ons all together, since one out of them could cause fatal errors. If add-ons are installed one by one, it is easier to identify and remove the add-ons causing problems.

After selecting one of these three options, a list of add-ons appears containing both the ones already installed and the ones that can be installed according to the selected option.

The first three columns of the list provide the following information:
- If the add-on is already installed (green), or not (white). The already installed add-ons can be installed again except if they are checked with the white symbol.
- If the add-on is official or suggested.
- The compatible operating system in case the add-on is only compatible with one specific.
Other information relate to:
- Name
- Release. Useful if there is more than one available release of the same add-on.
- Type. Only two types exist so far (plug-in and symbols) but other, such as languages, icons and so on, will be added in the future.
To make the add-ons search easier, it is possible to filter by category or type (on the left of the window) and by text (upper part of the window).

Once the desired add-on has been selected, a new window appears, where the setup procedure can be monitored. At the end, the system will ask a restart to apply the changes.

The following videos give an example for each setup type:

Filed under: english, gvSIG Desktop
06 mai 2013
22:02
Slashgeo (FOSS Articles): GDAL/OGR 1.10.0 Released, Now Includes Geocoding Client and Much More
sur Planet OSGeo
I was abroad last week. I'll catch up the recent geonews in the coming days.

The open source library at the core of most open source geospatial software and numerous commercial geospatial software just got better, version 1.10.0 of GDAL/OGR has been released a week ago. The previous major version 1.9.0 was released about 16 months ago.

From the release notes: "
- New GDAL drivers:
  - ARG: read/write support for ARG datasets (#4591)
  - CTable2: read/write support for CTable2 datum grid shift format
  - DDS: write-only support for DirectDraw Surface format (#5017)
  - IRIS: read support for products generated by the IRIS weather radar software (#4854)
  - MAP: read OziExplorer .map files (#3380)
  - MBTiles: read-only support for MBTiles rasters (needs libsqlite3)
- New OGR drivers:
  - ElasticSearch: write-only support to write into ElasticSearch databases (needs libcurl)
  - ODS : read/write support for OpenOffice .ods (Open Document Spreadsheets) (needs libexpat)
  - OSM : read-only support for .osm / .pbf OpenStreetMap files
  - PDF: read/write support for vector/structured PDF files
  - XLSX: read/write support for MS Excel 2007 and later Open Office XML .xlsx spreadsheets (needs libexpat)
- RFC 39: OGR Layer algebra methods : [trac.osgeo.org]
- Add a SQL SQLite dialect : � [gdal.org]
- Make GDAL loadable as a SQLite3 extension (named VirtualOGR) (#4782)
- /vsicurl_streaming/: new virtual file system handler designed to read in streaming mode dynamically generated files
- GDAL API_PROXY mechanism to run GDAL drivers in a separate process: � [gdal.org]
- Significantly improved drivers : PDF, SQLite, JP2OpenJPEG
- Add a geocoding client : � [gdal.org]
- Upgrade to EPSG 8.0 database"
Google Plus One [http%3A%2F%2Ftrac.osgeo.org%2Fgdal%2Fwiki%2Frfc39_ogr_layer_algebra%0A%0A%09%09Add+a+SQL+SQLite+dialect+%3A+%26nbsp%3Bhttp%3A%2F%2Fgdal.org%2Fogr%2Fogr_sql_sqlite.html%0A%0A%09%09Make+GDAL+loadable+as+a+SQLite3+extension+%28named+VirtualOGR%29+%28%234782%29%0A%0A%09%09%2Fvsicurl_streaming%2F%3A+new+virtual+file+system+handler+designed+to+read+in+streaming+mode+dynamically+generated+files%0A%0A%09%09GDAL+API_PROXY+mechanism+to+run+GDAL+drivers+in+a+separate+process%3A+%26nbsp%3Bhttp%3A%2F%2Fgdal.org%2Fgdal_api_proxy.html%0A%0A%09%09Significantly+improved+drivers+%3A+PDF%2C+SQLite%2C+JP2OpenJPEG%0A%0A%09%09Add+a+geocoding+client+%3A+%26nbsp%3Bhttp%3A%2F%2Fgdal.org%2Fogr%2Fogr__geocoding_8h.html%0A%0A%09%09Upgrade+to+EPSG+8.0+database%26quot%3B%0A%0A%0A&source=Slashgeo.org"] title="Publish this post to LinkedIn">
12:13
Nicklas Avén: A few questions and answers about the last posts
sur Planet OSGeo

I have had a few questions about TWKB and the websocket DEMO

When does the geoemtries actually load?
It is not obvious when the geoemtries actually gets loaded from the server to the browser.
That happens first time you click a layer. Then the geometries are streamed row by row via websocket to the browser which parses the geometry and adds it to the map, also geometry by geometry. Then if you switch off a layer and back again it is just loaded from Leaflet internally.

Can TWKB handle more than 2 dimmensions
Yes, TWKB can handle up to 7 dimmensions.

Can this websocket approach be used for writing back to the database?
Yes that is easy to implement. Just send the geometry back to nodejs with ws.send(), and insert it to the database. There is no function to import from TWKB into PostGIS. That is no big thing to write, but I don’t think there is the same performance need when posting back to the database, since that will be one or two geometries, not thousands of them. So the easiest is to just send it back as WKT and use ST_Geomfromtext to get it in the database.
10:08
gvSIG Team: gvSIG 2.0: Mirrors para descargas
sur Planet OSGeo

Una de las características más importantes de la versión 2.0 de gvSIG Desktop es el Administrador de complementos, desde el cual se pueden instalar los distintos paquetes (extensiones, complementos…, y más adelante los ficheros de traducción) directamente desde la aplicación. Esta versión ya está orientada totalmente a ello, no será necesario descargar las extensiones aparte, e instalarlas después sobre gvSIG. Por este motivo, se hace necesario tener varios servidores de descarga, varios mirrors para la descarga de los paquetes.

Hasta el momento, los servidores de descarga han sido facilitados por la Comunidad Rusa gis-lab.info, la Comunidad Rusa de gvSIG, LAPIG (Laboratório de Processamento de Imagens e Geoprocessamento, Universidade Federal de Goiás, Brasil), el Proyecto i3Geo (Edmar Moretti, Brasil), Geocuba (Cuba), ELOGeo (E-learning for Open Geospatial Community, University of Nottingham, Reino Unido), y Open Source Geospatial Foundation (OSGeo).

Esta nueva infraestructura permitirá descargar los paquetes de las distintas extensiones, complementos… desde gvSIG a través del administrador de complementos (menú Herramientas->Administrador de complementos). Para ello se han incluido las distintas URL de los servidores en un desplegable en la ventana inicial.

Por otra parte permitirá descargar los binarios de la aplicación (la versión completa con prerrequisitos) desde la tabla de descargas de la web de gvSIG, teniendo la opción de elegir de qué servidor queremos descargarla.

Desde el proyecto gvSIG queremos agradecer a todas las personas y entidades que han proporcionado estos servidores de descargas.

Filed under: gvSIG Desktop, spanish
05 mai 2013
23:22
Stefano Costa: Paesaggio e infrastrutture
sur Planet OSGeo

Oggi la sottosegretaria Borletti scrive:

#Report:promuovere il patrimonio culturale senza infrastrutture per viaggiare e’inutile.Ciaspetta un lavoro enorme ma la strada e’quella.

— Ilaria Borletti (@ilaborletti) 05 maggio 2013

Pochi giorni fa il presidente Letta ha detto:

Per questo dobbiamo rilanciare il turismo e, soprattutto, attrarre investimenti. Rimuoviamo quegli ostacoli che fanno sì che l’Italia per molti non sia una scelta di vita. Questo significa puntare sulla cultura, motore e moltiplicatore dello sviluppo, o sulle straordinarie realtà dell’agro-alimentare. Questo significa valorizzare e custodire l’ambiente, il paesaggio, l’arte, l’architettura, le eccellenze enogastronomiche, le infrastrutture stradali, ferroviarie, portuali e aeroportuali.

Parlando di patrimonio culturale onestamente la rete delle infrastrutture non è esattamente il primo punto che viene in mente. Chissà se si riferiscono al TAV o alla Cuneo-Ventimiglia, alla BreBeMi o alla provinciale 34 della Provincia di Siena. Sarei un po’ preoccupato, se il patrimonio culturale assumesse un valore solo come meta turistica.
20:10
BostonGIS: PostGIS 2.1 Manual in EPUB format
sur Planet OSGeo

Following PostgreSQL's lead, I thought it would be nice to provide PostGIS manual in ePub format. It turned out not to be a lot of work, but probably a lot more to fine tune it. I've changed Debbie (a PostGIS build-bot) to build this format and publish to PostGIS site whenever a change to PostGIS 2.1. You can download from [postgis.net] . The link next to EPUB.

I would appreciate if people could try it out on their eReader devices. On my Android tablet it looks pretty good, and had the nice feature of when I clicked on the epub link to download it, it added it to my library. I can't figure out how to click on the links (probably because I just use my desktop). and table of contents seems to crash the reader. On my windows firefox ePub viewer, it looks pretty yucky but much easier to navigate. I guess there are a LOT of differences with ePub readers.
18:59
Antonio Santiago: The OpenLayers fallen and Leaflet arise… sure???
sur Planet OSGeo
I wrote this post some months ago, before I publish the OpenLayers Cookbook, but I never published it thinking it could start a flame war instead a constructive thread.

Today, after a twitter conversation (thanks @Starefossen @brymcbride @erilem @mourner and @LeafletJS) I think it is time to publish it.

OpenLayers
OpenLayers is a great project. I think it is the most complete GIS project for creating web mapping applications. Its completeness makes it also a bit complex, but a complexity that is necessary.

OpenLayers allows to use raster and vector layers. Respect vector layers we can load data from different data sources (files, WFS servers, …) and with different formats (GML, GeoJSON, KML, …). OpenLayers allows to render geometries using different technologies (SVG or Canvas) in a way transparent to the user. Its design tries to follow as close as possible the standard concepts of features, geometries, attributes and tries to implement most of them (WMS, WFS, SLD, …).

In summary, OpenLayers tries to offer all the things a complete GIS project could need. Its desing has made having all this in mind and results in a big and complex architecture but, take into account, which is necessary to give response to all the requirements.
Leaflet
On the other hand we found a project like Leaflet, designed from the beginning with a philosophy close to ”make it without complexity” or ”offer only that things required to create a simple maps“.

Leaflet offers raster layers (from a tiled source), vector layers, markers and popups and, every day, a growing set of plugins adding more features to it: read GeoJSON files, clustering strategy, etc.

Leaflet is much more lightweight and, to create a simple map, it is more simple to use.
The secret behind the fame of Leaflet
IMO Leaflet has two main aspects that has made it the perfect option to be used in thousands of web pages: its look and feel and its coding style.

The Leaflet L&F is better than OpenLayers: buttons and layer switcher (among others) looks like an actual and fresh project instead like an almost 10 years old project like OpenLayers.

The Leaflet coding style is actual. The use of short namespaces and the chaining functions style (something like jQuery) makes it feel like a modern project and, probably, easier to use than OpenLayers.
What about Leaflet plugins?
Many of you can think “what about the plugins?” It is known one of the key aspects of Leaflet is the fact it offers a base code on which develop other plugins to make the platform better and greater. Yes, that is nice but is not always true.

For me, the growing set of Leaflet plugins remember the myriad of jQuery plugins. Most of them are great, awesome, but not all of them follow the same rules. Every developer can create plugins without a common design or architecture integration.

For example, the Leaflet.markercluster plugin (from Dave Leaver @daveleaver) is an awesome plugin that allows to make the same as the cluster strategy on OpenLayers, that is, group “points” which are too close and can overlap each other.

I must to say I start coding the AnimatedCluster strategy for OpenLayers after seen the Dave’s work, which I consider superior to mine.

The Leaflet.markercluster version is based in the concept of markers while the AnimatedCluster follow the more standard concept of feature.

To style markers in the Leaflet.markercluster you need to implement a iconCreateFunction and pass to the constructor which must be responsible to set the CSS style for each marker depending on the number of points it clusters (see the _defaultIconCreateFunction as a sample).

In the AnimatedCluster we have all the power of the features, geometries and styles OpenLayers offers us. We can create a vector layer, assign the AnimatedCluster strategy to it with some rules to style and automatically our layer will act as a cluster layer (please read the post Animated marker cluster Strategy for OpenLayers for more detailed explanation).

The fact OpenLayers is designed with many requirements in mind allow to work with a set of well designed pieces, like vector layers, features, geometries, styles, protocols and formats. But in contrast it adds some rigidness to implement new features that must conform the “global” rules.

On the other hand, Leafet lacks from a “global” design and, because of this, two similar plugins can follow to different implementation without the option of “reuse concepts” (think in another plugins that styles markers). But this lack of “global design” is what makes Leaflet be more flexible than OpenLayers.
Conclusions
IMO, both OpenLayers and Leaflet are great tools for different (but also similar) purposes. I consider Leaflet ideal for web pages with relatively simple maps (to create great visualizations with markers, popups, etc) but for a more GIS oriented solution I have no doubt of using OpenLayers.

Having that in mind it is easy to see there are a bigger number of sites requiring something like Leaflet instead of OpenLayers. The 90% of users requires a “simple map solution” instead a GIS solution. Having that in mind it is easy to see we are comparing a “simple map solution” with a GIS solution and I ask you: why?

As developer we have the pleasure to have two great tools on our bag. It is our responsibility to use the appropriate one on each situation.

Related Posts:
2:03
Nicklas Avén: Mapservice from Websocket with TWKB
sur Planet OSGeo

For those who don’t know what I am talking about TWKB is a compressed binary export format from PostGIS described here, and here.

It is just in the experimental stadium. The source for the PostGIS part can be found here

The Mapservice
What I find maybe most interesting is the websocket thing. I haven’t played with that before. Maybe this is old news for all of you out there. But websockets works cross-domain. So, a websocket can be approached from a page on my webserver or from a page on your desktop. That makes no difference.

You can download the index.htm from the demo:
The DEMO
put it someone on your computer, open it with a browser and it should load the maps.

You can also put this in a javascript:

var ws = new WebSocket('ws://178.79.156.122:8088'); ws.send(JSON.stringify({"nr":nr,"map_name":map_name}));

and you should get a reply if you use one of the map names that my “service” has.

If you don’t know the map names you can send:

ws.send(JSON.stringify({"request":"getcapabilities"}));

and you will get back a json-object with some metadata (That is demonstrated in the demo too)

All this is very unfinished, but it shows the idea.

Test it in OpenLayers too
The demo I have written is in Leaflet. That is just because it seemed easier to get started to test this in Leaflet. But it would be very interesting if someone took TWKB for a ride with OpenLayers (3). Since OpenLayers 3 promises webGL support a compressed binary format ought to be interesting.

What parameters the websocket takes
This is not even tested all of it, but here is what you can send to the wesocket:

map_name
srid (if not passed the srid of the table will be used, which can be found as default_srid in with getcapabilities)
precision how many decimals the coordinates shall have. Consider what unit your srid has. If not set the default value will be used
center.x & center.y Those coordinates gives the point that the result is ordered from. The idea is to get it order from the middle of the map, which makes sence if you are zoomed in and don’t see the whole map
inverted_lat_lng, boolean

As showed here it can be used directly from the websocket. Then there is not even any compiling involved.

I will, as I have said come up with a post about the technical aspects of the format, but I am afraid that will take some time. Meanwhile I will gladly answer any questions to make it easier getting started.
04 mai 2013
23:48
Sean Gillies: Dumpgj: JSON-LD and CRS
sur Planet OSGeo
The dumpgj script installed by Fiona 0.14 is among other things a vehicle for changing the way people think about GeoJSON.

There's a growing sense in the GeoJSON community that the crs object is over-engineered. It's rarely used, and those who do use it report that they would be just as happy with OGC URN strings instead of the existing objects. The new version of dumpgj adds an experimental:
```
"_crs": "urn:ogc:def:crs:OGC:1.3:CRS84"
```
to a feature collection when the input data is WGS84 longitude and latitude, as with Natural Earth shapefiles, and something like:
```
"_crs": "urn:ogc:def:crs:EPSG::3857"
```
for systems in the EPSG database (3857 is Spherical Mercator).

Additionally, dumpgj users can, with --use-ld-context, add more information to their GeoJSON files. The context object added to feature collections states more specifically what is meant by "Feature", "properties", "geometries", etc. Fiona's GeoJSON context looks like this:
```
{ "@context": {
  "Feature": "http://geovocab.org/spatial#Feature",
  "FeatureCollection": "_:n1",
  "GeometryCollection": "http://geovocab.org/geometry#GeometryCollection",
  "LineString": "http://geovocab.org/geometry#LineString",
  "MultiLineString": "http://geovocab.org/geometry#MultiLineString",
  "MultiPoint": "http://geovocab.org/geometry#MultiPoint",
  "MultiPolygon": "http://geovocab.org/geometry#MultiPolygon",
  "Point": "http://geovocab.org/geometry#Point",
  "Polygon": "http://geovocab.org/geometry#Polygon",
  "_crs": {
    "@id": "_:n2",
    "@type": "@id"
  },
  "bbox": "http://geovocab.org/geometry#bbox",
  "coordinates": "_:n5",
  "features": "_:n3",
  "geometry": "http://geovocab.org/geometry#geometry",
  "id": "@id",
  "properties": "_:n4",
  "type": "@type"
} }
```
I'm currently mapping GeoJSON's "id" and "type" to JSON-LD keywords, some other items to the GeoVocab spatial and geometry vocabularies, and giving the rest blank node identifiers until the GeoJSON community defines a namespace and permanent identifiers for them.

GeoJSON feature properties are the things that I think stand to benefit the most from a JSON-LD context. If a feature has a "title" property, is that an honorific like "Mr." or "Duchess of York"? Is it "NBA Championship"? Or something else? The dumpgj script has a --add-ld-context-item option that can be used to nail a property down a little more tightly. For example,
```
$ dumpgj --add-ld-context-item "title=http://purl.org/dc/elements/1.1/title" ...
```
adds:
```
"title": "http://purl.org/dc/elements/1.1/title",
```
to the feature collection's JSON-LD context. This is what "title" usually means in my applications.

Lastly, dumpgj will build the entire GeoJSON object in memory by default, but has a more economical --record-buffered option that only builds feature records in memory and writes them immediately to the output stream.
15:42
Jorge Arévalo: GDAL 1.10 released
sur Planet OSGeo

GDAL 1.10 was released past April. It includes, among others, the last improvements to PostGIS Raster driver, taking advantage of VRT and MEM drivers. Check PostGIS Raster driver page for further information.

I’m currently working on further improvements to the driver, thanks to Rapideye support and feedback. Apart from that, I’m collaborating with gvSIG CE and QGIS projects. So, upcoming news soon.
11:10
Free and Open Source GIS Ramblings: Sextante Modeler Evolution 1.0.8 to 1.1
sur Planet OSGeo

Sextante is quickly becoming the goto geoprocessing toolbox for me. I’ve been working with Sextante 1.0.8 on QGIS 1.8 and lately I’ve started looking into Sextante 1.1 for QGIS 2. This post highlights some of the main differences between the two versions. I’m sure there are many more hidden gems I have not discovered so far.

One thing you will notice if you have used previous versions of Sextante is that the new version comes with a simplified interface which groups tools into three categories: geoalgorithms, models, and scripts. If you prefer the old style grouping by algorithm source such as GDAL, GRASS, etc. you can switch to the Advanced interface.

Let’s start with the bad news: Models created in 1.0.8 are not compatible with 1.1 since many of the algorithms have been rearranged in new categories and Sextante cannot find them by their old names anymore, e.g.

1.0.8 … ALGORITHM:ftools:fixeddistancebuffer
1.1 … ALGORITHM:qgis:fixeddistancebuffer

The great news is that the modeler has been improved greatly. Model representations now show the flow of input and output data through the model steps much more clearly:

Sextante 1.0.8 modeler

Sextante 1.1 modeler

I also found the new modeler much more stable – no crashes so far. *fingerscrossed*

Another nice new feature is Sextante commander which can be started using the shortcut Ctrl+Alt+M. It’s a quick launch solution for all Sextante algorithms:

At FOSS4G, I’ll be presenting some work I did evaluation OSM using Sextante 1.0.8. I’d love to hear how you are using Sextante.
03 mai 2013
23:33
Jackie Ng: One request to rule them all
sur Planet OSGeo

Seriously, image Data URIs are the absolute bomb!
18:38
FOSS4G 2013 News: Press Release 6th May 2013
sur Planet OSGeo

The Draft FOSS4G’13 Programme is released!
The FOSS4G community has spoken! The open voting process (http://2013.foss4g.org/press-release-10th-april-2013/) closed with a record response of people sifting and reporting on their favourite submissions from a selection of over 320 abstracts. It clearly wasn’t always an easy choice, and the Local Organising Committee (LOC) had a challenge to distil the responses down into an eight stream programme: that still leaves just over 200 papers, presentations, and workshops for the FOSS4G’13 delegate to choose from! There really is something for everyone here – and lots of it, from ‘deep dives’ to ‘guided introduction tours’ of all the major applications, case studies, applications and just some plain odd-ball stuff!

To make the process of navigating the agenda as simple as possible a tagged programme for the presentations is available at http://2013.foss4g.org/provisional/, while the workshops can be viewed at http://2013.foss4g.org/provisional/workshops/. The final programme will be announced on Monday 17th June. For any number of reasons we may have to accommodate author changes, making the programme provisional up until that point. The LOC would really like to give a huge shout out to all those people who contributed abstracts and proposals – we’re hugely grateful. And a big congratulations to all those whose submissions were successful! Now all that remains is for you to register. The Early Bird discount closes on May 31st. To sign up simply visit: http://2013.foss4g.org/registration/.

Notes to the Editor:

About FOSS4G (2013.foss4g.org): FOSS4G is the global conference for Free and Open Source Software for Geospatial, hosted by the Open Source Geospatial Foundation (OSGeo) and organised by a Local Organising Committee. FOSS4G will be held in the United Kingdom for the first time in 2013, at the East Midlands Conference Centre (http://www.nottinghamconferences.co.uk/emcc/) in Nottingham, from 17th to 21st September. FOSS4G 2013 will follow on from the Association for Geospatial Information (www.agi.org.uk) annual GeoCommunity event held in the same venue. These two conferences form a part of the geospatial focused events happening across the UK in September (www.maptember.org).

About OSGeo (www.osgeo.org): The Open Source Geospatial Foundation, or OSGeo, is a not-for-profit organization whose mission is to support the collaborative development of open source geospatial software, and promote its widespread use. The foundation provides financial, organizational and legal support to the broader open source geospatial community. It also serves as an independent legal entity to which community members can contribute code, funding and other resources, secure in the knowledge that their contributions will be maintained for public benefit. OSGeo also serves as an outreach and advocacy organization for the open source geospatial community, and provides a common forum and shared infrastructure for improving cross-project collaboration. The foundation’s projects are all freely available and useable under an OSI-certified open source license http://www.opensource.org/licenses/.

Media Sponsorship: FOSS4G would welcome the support and encouragement of media sponsors. Full details are available at http://2013.foss4g.org/media-sponsorship-package/.

Logo: The FOSS4G logo can be downloaded from: http://2013.foss4g.org/Style/.
17:10
Free and Open Source GIS Ramblings: Print Composer 2.0 – Take #7
sur Planet OSGeo

Today’s post: More print composer overview magic!
Inverted Map Overviews
Thanks to the “Invert overview” option, we can now chose between highlighting the detail area (left example in the image) or blocking out the surrounding area (right example).

The “Lock layers for map item” option can come in very handy if you want to reduce the number of layers in the overview map while still keeping all layers of interest in the main map.
14:17
GeoServer Team: GeoServer training in Milan, 6/7 June 2013
sur Planet OSGeo

If you are looking for GeoServer training, save the date: GeoSolutions will be providing a two days long introduction to GeoServer 6/7 June 2013 in Milan.

The training will be held in Italian by GeoServer core contributors, and will cover a basic introduction to GeoServer, setting up vector and raster data, basic and advanced SLD styling, raster data tuning, integration with Google Earth, tile caching with the integrated GeoWebCache, delivering and filtering vector data with WFS, security, integration with the rest interface and setting up for production. The experience will be hands on, with one computer per participant, with discounts for university students.

If you are interested but cannot make it, or would like to get training in another language, go have a look at the GeoServer training page to find more training opportunities.
11:59
Simone Giannecchini: Developer's Corner: MapStore 1.2.0 released!
sur Planet OSGeo
Dear All,
we are proud to announce that we just released MapStore version 1.2.0.

This is the latest official release of MapStore, the simple and intuitive way to create, save and share maps.
MapStore is based on the GeoExplorer Open Source framework and is licensed under the GPL license.

This new version is available in 4 different flavours:
Here is a list of the most important improvements included in this release:
- added GeoNetwork integration
- added installer for Windows systems
- added customPanels configuration option
- made easier to install and customize printing module
- added basic auth and cookies support to RingoJS debug proxy
- refactored and enhanced xmlJsonTranslate (now servicebox)
- added "no click" info tool on the map
- enhanced marker editor with image selection tool
- many additional bugfixes
If you need further info look at the complete list of included issues.

It is worth to point out that in this release we also releasing a template suitable for integrating MapStore with GeoNetwork to create GeoPortal similar to the Florence OpenGeoData portal.
All necessary information to enable this in MapStore, or to get the customized GeoNetwork version, are in the WIKI pages here.

With MapStore you can mashup contents from Google Maps, OpenStreetMap, MapQuest, Bing or specific WMS services provided by you or third party content providers.
MapStore uses internally GeoStore, (the GeoSolutions Open Source engine for resource storing and retrieving) for managing users as well as maps definitions. Moreover MapStore uses Http-proxy to communicate with remote servers, such as the third party WMS services used in your maps.

Visit our online demo or download the MapStore binary, read the Quick Start guide and start to create and share your own maps. If you need more info, please check to the complete documentation wiki.

If you have questions or if you just want to talk to us about using our tools in your project, please, subscribe to the mailing list here. In any case, do not hesitate to contact us.

Happy mapping to everybody!
The GeoSolutions team,
8:50
gvSIG Team: gvSIG 2.0: How to create symbol libraries (II)
sur Planet OSGeo

In the former post we saw how to create a new symbol library from image files. Once the library is created it may be interesting to share it with other users and even with the community in general.

With gvSIG 2.0 we can easily do it as we can generate a package containing the library and install it in any other gvSIG from the add-ons manager.

It looks easy, isn’t it? It’s just what it is!

From the symbol library created in the former post, we are going to generate our package. For that, we have to select the option “Create package” within the menu Tools/Symbols. Then it will appear a window like this:In this window we can see all the symbol librearies available in our gvSIG, in this case “gvSIG Basic”, which is the default library, and “Open Icon”, which is the one we have created. Once selected the latter we will click on Next.

Then we get a dialog box with a form where we will fill in the “metadata” of our package. In this case the data could be similar to this:

The option “Is official” should not be checked when the package is generated by the community.

We will get a dialog box with four options to be defined:

- Package file (Archivo del paquete). It is the folder where the generated package will be saved in. By default, packages are saved in the gvSIG install folder, inside a folder called “install” (usually in “/home/usuario/gvSIG-desktop/gvSIG-desktop-2.0.0/install”. We will keep it without changes so we know where to find the package afterwords.

In case we want to share the package with the community through the Internet it is worth it to pay attencion in the following steps. Otherwise you can left the default options and go directly to “We already have our package containing the symbol library ready to share…”.

- Creating the package index. We will only check this option if we want to share the package. The package index is a GVSPKI file which is useful to install it on-line from gvSIG. No need to check it in any other case.

- Download URL. This is the most important step if we want our package to be available through the Internet.

In our case, assuming that we want to use the official gvSIG downloads server: [downloads.gvsig.org]

And now we have to add the name of the package (we can copy it from the text box “Archivo de paquete”). For example, in our case in package file we have “/home/alvaro/gvSIG-desktop/gvSIG-desktop-2.0.0/install/gvSIG-desktop-2.0.0-Open Icon Library-1.0.0-0-final-all-all-j1_5.gvspkg” so the Download URL would be: “ [downloads.gvsig.org] Icon Library-1.0.0-0-final-all-all-j1_5.gvspkg”

- Package index file. Similar than “Package file”.

We already have our package containing the symbol library ready to share.

We can make the following test to check that we followed the steps correctly (with gvSIG closed).

- Go to your user folder and browse to “gvSIG/plugins/org.gvsig.app/Symbols”. Delete the folder “Open Icon”.

- Open gvSIG and check that the deleted symbol library doesn’t exist.

- Go to the add-ons manager (menu Tools/Add-ons) and select the option “Installation from file (install add-ons contained in a .gvspki or .gvspks file)”. Browse to the folder where our GVSPKS file is (in my case: “/home/alvaro/gvSIG-desktop/gvSIG-desktop-2.0.0/install/gvSIG-desktop-2.0.0-Open Icon Library-1.0.0-0-final-all-all-j1_5.gvspkg “) and select it.

- Press Next. In the list of available addons it should be one called “Open Icon” which is the one we generated. Check also that the description is ok. Install it and despite we get a message saying that we have to restart gvSIG, it is not necessary in this case so we could check that the new symbol library is already available.

In following posts we will share some symbol libraries that we are now creating in order that the community can use them and give more information about creating symbols (for example from a TTF font).

And, of course, we encourage you to create your own symbol libraries and share them with all the community.

Filed under: english, gvSIG Desktop Tagged: gvSIG 2.0
02 mai 2013
20:22
SourcePole: QGIS Cloud and Sourcepole are sponsoring Öcher-Safari
sur Planet OSGeo

QGIS Cloud and Sourcepole are proud to be official sponsors of the team Öcher-Safari, attending the Allgäu-Orient-Rallye. One of the last adventures in the world of cars. Sourcepole serves the team with know how, infrastructure and more. Information about the team and the charity ideas of this event you can find on Öcher-Safari and the official web site of the Allgäu-Orient-Rallye.
16:00
Nathan Woodrow: Installing QGIS using apt on windows (OSGeo4W)
sur Planet OSGeo
Here is a handy tip to be able to install and update OSGeo4W packages, things like QGIS, GRASS, etc, using the apt utility from OSGeo4W. apt is a command line utility that you can install using OSGeo4W and then run using the OSGeo4W Shell.

First install apt via OSGeo4W

Now open the OSGeo4W Shell

from here you can run the apt utility.

The basic commands are apt update, apt install {package}, apt upgrade
Installing nightly QGIS
For a quick example we will install qgis-dev.

From the shell we can just run:
```
apt setup
apt update
apt install qgis-dev
```
apt will install all the needed dependencies

Done!
Script for updating nightly QGIS
So the good thing about using apt is if you wanted to make a quick batch file that you can run to update to the nightly build it's as simple as
```
@echo off
set OSGEO4W_ROOT=C:\OSGeo4W
set PATH=%OSGEO4W_ROOT%\bin;%PATH%

apt update
apt install qgis-dev
pause
```
Now you can just run the batch file to update your QGIS to the nightly build.
Extra tip
If you just want to upgrade all the packages you have installed you can do:
```
apt setup
apt upgrade
```
Simple
15:31
Jackie Ng: MapGuide tidbits: MgByteReader and friends
sur Planet OSGeo
This one's a bit of a post for newbies, so you can skip it if you already know this stuff :)

If you look at the various bits of the MapGuide API, you'll probably see lots of references to MgByteReader lying around. An API will either return one or require one as part of its method parameters.

What is a MgByteReader? A MgByteReader is basically a MapGuide analogue to your Stream class in .net/Java and serves the same purpose: an unified I/O abstraction for things that can be fed into the MapGuide API and things that are returned from the MapGuide API. Things like.
- Images (of rendered maps/selections)
- Resource Data files (to download/upload)
- XML files (to/from the repository)
- DWF files (for DWF ePlots)
So if you're given an MgByteReader from a particular API, what can I do with it? Similarly, if an API requires passing in a MgByteReader, how can I make one?
Here's a diagram I made up that should explain everything to you.

Since MgByteReader is basically a stream, you might be wondering if the .net/Java/PHP wrappers to the MapGuide API provides any adapters to allow MgByteReader objects to be consumed as Stream objects, so you don't have to do any manual conversion. For PHP and Java, you're out of luck. You'll have to dump the MgByteReader into a supported form as per the above diagram, and then work from there.
For .net however, I've already solved this problem for you :) If you're using the Maestro API (that wraps both the official MapGuide API and the mapagent interface), for APIs that return MgByteReader objects Maestro provides wrapper APIs that return System.IO.Stream objects instead. Similarly for APIs that take MgByteReader parameters, Maestro's wrapper API takes System.IO.Stream objects.
If you're not using Maestro, there's a MgReadOnlyStream class I wrote for mg-desktop that can easily be reused for your own .net applications if you require a System.IO.Stream adapter. MgReadOnlyStream provides mg-desktop an easy way to convert the output of a rendering service API into something that requires a System.IO.Stream (eg. a System.Drawing.Image). That's pretty much the gist of how our mg-desktop viewer works, taking MgByteReader objects from the rendering service, wrapping it into a MgReadOnlyStream and feeding that to a System.Drawing.Image, to then be painted onto a WinForms control surface.
Hope this helps.
11:12
gvSIG Team: gvSIG 2.0. Administrador de complementos
sur Planet OSGeo
Quizá una de las novedades potencialmente más útiles de gvSIG 2.0 sea el administrador de complementos (aunque gvSIG 1.12 ya traía una primera versión), cuyas principales ventajas son:
- Se pueden actualizar complementos sin esperar a la siguiente versión de gvSIG.
- Se puede personalizar la instalación de gvSIG.
- Se pueden compartir fácilmente complementos como símbolos, idiomas, scripts, etc.
Antes de explicar el funcionamiento de la herramienta conviene dejar claro los tipos de distribución de gvSIG disponibles ya que en función de la distribución a partir de la cual instalamos gvSIG, podremos seleccionar distintas opciones dentro del administrador de complementos:
- Distribución estándar. Contiene los paquetes de la instalación por defecto más un conjunto reducido de complementos. Corresponde con la distribución “con prerrequisitos incluidos” de la tabla de descargas.
- Distribución online. Contiene la instalación básica y mínima de gvSIG pero sin funcionalidad. Para finalizar la instalación de complementos es necesario disponer de conexión a internet. Corresponde con la distribución “sin prerrequisitos” de la tabla de descargas.
El administrador de complementos nos permite, por un lado, modificar la instalación por defecto añadiendo o quitando complementos con respecto a los inicialmente propuestos, y por otro instalar o actualizar complementos posteriormente. En el presente post vamos a explicar el funcionamiento de la herramienta suponiendo que gvSIG ya está instalado. No obstante la mayoría de la información es válida para la parte de la instalación en la que se ejecuta el administrador de complementos.

El administrador de complementos está disponible en el menú Herramientas/Administrador de complementos de gvSIG 2.0. Al ejecutarlo lo primero que nos aparece es un cuadro de diálogo en el que se nos muestran las siguientes tres opciones, tal y como podemos ver en la imagen:
- Standard installation (install addons contained in the gvSIG standard distribution)
- Installation from file (install addons contained in a .gvspki or .gvspks file)
- Installation from URL (install addons from a remote repository)
Veamos qué implica cada una de ellas:

Standard installation

Esta opción solo está disponible en caso de que gvSIG se haya instalado desde la distribución estándar y solo permite instalar complementos incluidos en ella, normalmente los complementos más populares y con un mayor nivel de estabilidad dentro de todos los disponibles. Por lo tanto es la opción más segura en el sentido de que no es probable que los complementos que se instalen contengan errores graves.

Otra cosa a tener en cuenta es que no se requiere conexión a internet en el momento de la instalación.

Installation from file

La principal ventaja de esta distribución es que te permite instalar complementos compartidos por otra persona sin que necesariamente tengan que estar en el repositorio oficial de paquetes de gvSIG. No obstante también es útil si se quiere instalar un complemento oficial de forma individual previamente descargado. En este enlace [1] pueden consultarse todos los complementos disponibles para la versión 2.0.

Installation from URL

Mediante esta opción podemos acceder a los complementos disponibles en distintos repositorios. El URL marcado por defecto corresponde al repositorio específico de la distribución instalada, el cual contiene los todos los complementos compatibles con esa distribución, incluyendo complementos en desarrollo.

El resto de URLs corresponden a mirrors del repositorio oficial genérico de la versión instalada (gvSIG 2.0 en este caso) a través del cual podremos acceder a los complementos compatibles con todas las distribuciones de una determinada versión.

Esta opción es la indicada si estamos interesados en probar complementos en desarrollo ya que nos muestra todos los disponibles independientemente de su estado de desarrollo. Por este motivo no es recomendable instalar complementos de forma masiva ya que alguno de ellos podría causar daños en la aplicación. Si los instalamos uno a uno es más fácil detectar y eliminar el complemento que da problemas.

Una vez seleccionada una de las tres opciones accederemos a la lista de complementos que contiene tanto los elementos instalados como los disponibles para instalar, lo cual variará según la opción que hayamos seleccionado.

Las tres primeras columnas de la lista nos informan respectivamente sobre:
- Si el complemento está ya instalado (verde), o no (blanco). Los complementos instalados pueden volver a instalarse salvo si están marcados con un candado.
- Si el complemento es oficial y recomendado.
- El sistema operativo con el que es compatible en caso de que solo sea compatible con uno específico.
El resto de información es:
- Nombre
- Versión. Útil si hay más de una versión disponible de un mismo complemento.
- Tipo. Actualmente solo existen dos tipos (plugin y symbols) pero en el futuro se añadirán otros como idiomas, iconos, etc.
Para facilitar la búsqueda se puede filtrar por categoría y tipo (parte izquierda de la ventana) y también se puede filtrar por texto (parte superior de la ventana).

Una vez seleccionados los complementos a instalar pasaremos a una ventana en la que podemos seguir el proceso de instalación. Finalmente se nos informa de que para aplicar los cambios es necesario reiniciar la aplicación.

Os dejamos unos vídeos en los que se muestra un ejemplo de cada tipo de instalación:

Filed under: gvSIG Desktop, Products, spanish Tagged: addons manager, administrador de complementos, gvSIG 2.0
01 mai 2013
17:57
Bjorn Sandvik: Det Norske Kartselskapet
sur Planet OSGeo
Dette er en samleside om saker som angår Det Norske Kartselskap. Selskapet har fått stor oppmerksomhet i media i den siste tiden, for å bruke svært ufine metoder for å lure kunder til å betale dyrt for et produkt de ikke trenger. Det er særlig offentlige virksomheter som er ført bak lyset, og det er dermed dine og mine skattekroner som sløses bort på overprisa karttjenester.

Hvorfor unngå Det Norske Kartselskap og tjenesten Atlas.no?
- Les erfaringer fra andre virksomheter som har blitt oppringt av Det Norske Kartselskap.
- Prisen samsvarer på ingen måte med tjenesten du får.
- De samme tjenestene som Det Norske Kartselskap tilbyr kan du få gratis eller mye rimeligere andre steder.
Eksempler på hva kunder har betalt for tjenesten:
Det Norske Kartselskap oppgir selv at de har flere tusen kunder blant både store og små organisasjoner innen privat og offentlig sektor. I følge E24 hadde selskapet en omsetning på over 17 millioner i 2011.
- Gravferdsetaten i Oslo har betalte 754 000 kr på et år for oppføring av etatens 19 gravplasser i Oslo (kilde).
- Blodbanken på Ahus har brukt 3,7 millioner på karttjenester fra Det Norske Kartselskap (kilde).
- Åsane videregående skole fikk regninger på 130 000 kr (kilde).
- Sola videregående skole betalte 70 000 - 80 000 kr for å få logoen sin på et kart (kilde).
- Bergen maritime skole har betalt 100 000 for tjenesten (kilde).
- Lotteritilsynet har betalt flere hundre tusen for tjenesten (kilde).
- Stavanger parkering brukte på et år 800 000 kr på karttjenester fra Det Norske Kartselskap (kilde).
- Oslo universitetssykehus har brukt 1,4 millioner kroner på en karttjeneste som finnes gratis på nett (kilde).
- Geilomo barnesykehus har brukt 400 000 kroner på tjenesten (kilde).
- Bergen og omland havnevesen har brukt 250 000 kroner på tjenesten (kilde).
Artikler om Det Norske Kartselskapet i media
- Fakturafobi. Leder i Dagens Nærlingsliv 29. april 2013.
- Slik opererer Kartselskapet - ifølge kundene. Aftenposten 26. april 2013.
- Gravferdsetaten betalte 730 000 på ett år. Aftenposten 26. april 2013.
- Brukte 800.000 unødig. NRK.no 26 april 2013.
- Statens kartverk føler seg misbrukt av Kartselskapet. Aftenposten 25. april 2013.
- Blodbanken på Ahus brukte 3,7 millioner på kart. Bjarne laget det gratis på noen kvelder. Aftenposten 21. april 2013.
- Bruker milliarder på feilkjøp hvert år. Aftenposten 21. april 2013.
- Sendte kartregning til skoleelever. Aftenposten 21. april 2013.
- OUS brukte 1,4 millioner på unyttig karttjeneste. Aftenposten 21. april 2013.
- Har sagt opp karttjenesten. NRK.no 21. april 2013
- Ahus brukte 3,7 mill. – vet ikke hva de kjøpte. Aftenposten 18. april 2013.
- Advarte Oslo-skoler mot kartselskap. Aftenposten 18. april 2013.
- Arbeiderpartiet og politiet betalte for omstridt karttjeneste. Aftenposten 18. april 2013.
- Altaposten frifunnet i PFU. Altaposten 27. mars 2013.
- – Irritasjonen ble fort til forbannelse. Atlaposten 5. oktober 2012.
- Svindles av katalog-haier. Vårt land 21. juli 2010
Hvem leverer innhold til Atlas.no?
- Norgeskart og flyfoto leveres av Norkart (WebAtlas.no).
- Verdenskart og skråfoto leveres av Microsoft (Bing Maps).
- Trafikkmeldinger leveres av P4 (Trafikkflyt.no). P4 opplyser om at de har tatt en vurdering av sin leveranse til dette selskapet og på bakgrunn av den siste tidens presseomtale og negativ oppmerksomhet besluttet å be dem stanse bruken av sitt innhold umiddelbart.
Nettadresser som er registrert av Det Norske Kartselskap (kilde)
Det Norske Kartselskap i sosiale medier
- Facebook
- Twitter
- Google+
- Blogg
16:00
Nathan Woodrow: SVG textures + blend modes = Cool QGIS Maps
sur Planet OSGeo

Did you know you can use textures to fill a polyon in QGIS? No? Well you do now!

The cool thing is you can get results like this with a simple SVG and a texture.

So how do you do it? Lets give it a go.

First grab a texture you want from [texturelib.com]

Install Inkscape, or any other tool that can create svgs with textures.

Drag and drop your texture into Inkscape and embed the texture into the SVG:

Twaek any settings you need in Inkscape and save it somewhere QGIS can find.

Tip: You can configure extra search paths for svg in Options -> System -> SVG Paths

Open QGIS and load a polygon layer

Change the symbol type for the style to SVG fill and selet your SVG

Hit apply.

Opps that's not right

Enter the handy blend modes added by Nyall.

Change the blend mode to Soft Light and move the layer to the top of the drawing list

SWEEEET!!!!

Now go and make some pirate maps.
13:14
OSGeo News: Open Source Geospatial Laboratory established at the University of Southampton, UK
sur Planet OSGeo

OSGeo News: Open Source Geospatial Laboratory established at the University of Southampton, UK
10:44
Jo Cook: my first hackathon
sur Planet OSGeo

In all the years that I’ve been involved with open source, I’ve been a committed advocate for the idea that you don’t need to be a coder to get involved. I’m definitely not a coder- I can write a script or two, and have been known to submit bugs, but that’s as far as it goes. My strengths are in identifying and fixing problems, and getting other people enthused. That’s all well and good, but hackathons- they are for real coders, right? Why expose my terrible deficiency of coding skills to the world? It turns out, I was wrong!

So, for various reasons I don’t need to go into here, I found myself at the first MapAction/AGI Technical SIG Hackathon at our company offices in Epsom, with a mix of 40 other people: coders, MapAction volunteers, Astun colleagues, and other interested parties. MapAction had done a lot of leg-work before the event, identifying particular problems that they wanted to try and solve, with enough variety that everyone could find something of interest. As one of my current work projects involves metadata gathering, when I saw a hack around implementing a metadata gathering script in Quantum GIS, working with an existing python script (thanks Tyler), I thought it was something I could have a go at. The guy I teamed up with had even less scripting experience than me, but was also interested in the end result. Other teams looked at data visualisation, and the fantastically named “Dirty Data Dashboard”, that deliberately creates invalid or “dirty” data for use in training.

With very little experience of implementing python plugins in Quantum GIS, we had a brief attempt at using the Script Runner plugin to access the script. This definitely seems like a useful first approach, but the learning curve of adapting the script to interact with Quantum GIS (for example to return results to the logging console) was more than we could manage in the time available. Furthermore, I think it would be useful to create a wrapper for Quantum GIS, rather than rewriting the original code and risking it no longer working as a stand-alone script. Instead, we worked on extending the script to return more “human-readable” results. For non-coders, this was definitely achievable in the time available, so we had the nice fuzzy feeling of actually having a result at the end of the day.

Time for another first! Well, technically a second, but I’m not sure this counts. I love GitHub, and use plenty of repositories, but as a non-coder, putting your own code on the site for all and sundry to see is quite intimidating, and there are tales of people getting criticised publicly for nothing more than producing imperfect code. Not only does that put me right off, but it also makes me quite angry because it’s deeply elitist and non-constructive. However, once we’d extended this python script, re-committing it back to GitHub was the natural thing to do. Cue much googling on forking a repository, committing back to GitHub from my local copy, then issuing a Pull Request. And yay, it was accepted!

All in all, the MapAction hackathon was definitely a success. Lots of good things were achieved, and I would imagine that it will be repeated fairly soon. There’s no moral to this story, and I still think of myself as a non-coder, but this was just a first toe in the water of engaging differently with the open source world. Finally though, I would say that if you do consider yourself a non-coder, don’t be put off from attending a hackathon, as there will definitely be something you can contribute to.

Skip to page: 1 2 3 ... 53

← Blog Interopérabilité &...

Communauté	Ressources	L'emploi	Le marché	L'association	Fils RSS
Forum Blogs Wiki Planet Carte des membres Sites amis	Annuaire Agenda Biblio Netvibes Fiches AMO-CNIG Paris PCGIS Téléchargements	Offres d'emploi Banque de CV Carte des CV Formations Démarche Métiers	Geo-Entreprises Geo-Communiqué Appels d'offres	L'association Qui sommes-nous ? Nous aider Bienfaiteurs Partenaires Historique Statuts	Tout le site Job Géomatique Services GeoBlogs ...	Faire un don Mentions légales

Le portail francophone de la géomatique

Feeds

Planet OSGeo