Monday, December 7, 2015

The 11th international gvSIG conference


It has all in all been a good conference, even if it was our first gvSIG conference since the migration from uDig to gvSIG. 
 
The community gave us a warm welcome and apart of all the presentations, we also spent a lot of time developing together at the code sprint, working on integrating gvSIG in OSGeo 4 Windows, chatting about gvSIG for water management... and obviously having great fun :-)


For those interested, here the slides of the presentations we gave:

1) Digital field mapping with Geopaparazzi and gvSIG

http://www.slideshare.net/moovida/digital-field-mapping-with-geopaparazzi-and-gvsig

2) New tools for LiDAR, forestry, river management and hydrogeomorphology in gvSIG

http://www.slideshare.net/moovida/new-tools-for-lidar-forestry-river-management-and-hydrogeomorphology-in-gvsig

3) GIS tools for water supply systems: an implementation using JGrasstools and gvSIG

http://www.slideshare.net/silli/epanet-in-gvsig



 

Sunday, November 22, 2015

Bye bye uDig, hello gvSIG world!

Bye bye uDig


This post should have been written ages ago. But I have never been ready to do so. And it still is very difficult for me to properly write something about my exit from the uDig community. The Open Source ecosystem is a particular one and people not involved in the same way understand things differently. But I love the Open Source ecosystem, it gives you always a new possibility even if it might seems there is none.

So I will try to stick with the facts, even if being my personal blog some passion could seep through.

We have loved uDig for many years. We have contributed about everything that means raster analysis in uDig and have been in the Project Steering Committee for several years. We fought the trend that was keeping uDig "only" an SDK for developers instead of a desktop GIS for the community. And well, it is time to say that we failed.

My guess is that uDig will never be a widely used desktop GIS, i.e. a standalone GIS. uDig will always be an amazing SDK. Something you use to build great location aware applications.

uDig has always suffered from the fact that there were almost no contributions in the last 5 years. No resources/interest to the fix bugs that were stopping people from using it. uDig didn't evolve much. Resources were really low and at some point I remember always the same 3 developers trying to get uDig up and running, adding stuff, making it work: Jody, Frank and myself.

Then, in this low resources situation we made a huge error. We started the migration into the Locationtech Fundation. Which is not an error per se, but in the conditions the community of developers was in, that has been an irresponsible move. uDig entered a kind of limbo from which I think it still didn't exit. There was no real well working version available and all resources were in the migration process. A process that lasted about 2 years. In the meanwhile we lost possible contributions (at least one big I know of), since it was not clear were to contribute: the old was old, the new was never finished.

In the middle of all this mess, in which Jody and Frank were doing a big big voluntary work and keeping the uDig ecosystem on their shoulders alone (kudos for all that to you guys), I started to retire from uDig. Several long discussions at the Nottingham Foss4G opened my eyes an made me understand that I was in the wrong project.
uDig was on the way to be an only-SDK project (if you disagree with that i will be happy to openly discuss about it) and this was no longer something I would be part of.
Also, the Locationtech environment was not exactly what I expected it to be (I am not saying good or bad, I am just saying not the right thing for me).

So we left... without knowing where to go. For a couple of years we were working without a desktop GIS. Something that had never happened before... and it felt really wrong!

But our clients needed our tools, so we created the standalone version of the spatial toolbox, S.T.A.G.E.
Funny thing is that once the tool was standalone, also QGIS users approached us, because it was handy. They didn't like it in uDig, but if they could use it with QGIS it was ok :-)

Hello gvSIG world!


Well, time passed and it was still unclear to us were we would land. uDig was still blocked somewhere in the migration process... when a company of friends of ours invited us to come to the gvSIG conference in 2014, offering to pay travel and accommodation. They were interested to see our Geopaparazzi digital field mapping tools inside gvSIG to use them in projects in development countries. While I was still emotionally too bound to uDIG to cheat on it, Silvia was very sensitive to the words "development countries", so we decided to accept the offer.

We had a private meeting with the gvSIG Association members and developers to discuss the possibilities to work together and migrate our JGrasstools and Geopaparazzi libraries into gvSIG.
I have to admit they were extremely helpful and we also made a session to quickly get me up and running with gvSIG development.

After the conference we came back to reality... with no funding we could never migrate... the process was simply too big. So time passed and nothing happened. Secretly I hoped the uDig migration nightmare would be over and we could go back to normal life.

A couple of months ago we decided to end the suffering and at least try something. So I contacted Alvaro Anguix from the gvSIG Association and discussed with him the blockers we had (mainly about the projection system) to start using gvSIG. After some discussions, we decided that it would be best for me to spend a week with them at the gvSIG headquarters in Valencia, hacking, coding and discussing the way thing should or should not be.

At the begin of this month I did exactly what that. I tried to prepare myself as much as possible in order to have tons of complex questions for their developers and flew to Valencia.

I had the luck to sit for a week near gvSIG's main architect and talk daily also to other developers, as well as discuss about user needs and features and Open Source philosophy. I found gvSIG to be a nice community, even if until that moment focused heavily on the latin world.

So let me show you what we were able to achieve in the last weeks.

I started with the aim to:
  1. bring the water management module based un Epanet into gvSIG
  2. bring support for geopaparazzi databases to gvSIG

The water management module

Porting that module has been fun. The biggest difficulty has been understanding the styling engine of gvSIG, which is way different from uDig.    

So for now we have a HydroloGIS menu inside which an Epanet menu appears. From there you can do the usual stuff: create new project files, link the layers properly together the Epanet way (filling in the attributes) and style layers:


When you run the module, the usual wizard appears. Now that wizard remembers exactly everything you entered before, which comes in handy when working a lot with simulations.



Results are stored directly into a sqlite database. One file can also contain more simulation runs.

The results can be visualized in two ways:
  1. view the state of the network in one moment (in time) on the whole map. This now looks way better than in uDig, since gvSIG allows for a nice legend to be updated. So in the layerview you will see also the values for each colored pipe or pump or junction.
  2. view the whole timeline of one of the pieces of the pipeline.



If you are interested to know more about it, come to this year's gvSIG conference, Silvia will give a talk about it:

GIS tools for water supply systems: an implementation using JGrassTools and gvSIG


Geopaparazzi support

gvSIG now has direct Geopaparazzi database support. That means that as you add any WMS, shapefile or tiff layer, now also an option for Geopaparazzi appears.


Once you select the database file, some information about the database will appear, as well as the layers it will create on loading:


You have the option to import it to temporary layer, but also to create shapefiles from the database.
The second option gives more features and is the suggested way to go.

Once imported, the layers will be generated with their own default style and labeling:








The media layer can now be queried with an own tool:







So if you select one or more images, they will be opened:


gvSIG now also has the tool to create a tileset (for Geopaparazzi basemaps) from the current view:



If you are interested in this, again, come to this year's gvSIG conference, I will be giving a talk about it. :-)

Digital field mapping with Geopaparazzi and gvSIG

The spatial toolbox: JGrasstools

Since things were going really fast (I was in Valencia and working around 15 hours a day, no partying for me this time :-) ), I decided to also give the spatial toolbox a try.

One thing that helped, was the fact that gvSIG is licensed under GPL license, which is the same one I love and JGrasstools are licensed under. That gave huge advantage during the integration.

This took a bit more work, also after the Valencia days, but it is already usable:






Obviously the layers are taken from the current selected map view and the coordinates (as in the above extract basin module) are set form clicks on the map.



If you are interested in this, again-again come to this year's gvSIG conference, I will be giving a talk about it. :-)

New tools for LiDAR, forestry, river management and hydro-geomorphology in gvSIG

Styling rasters

I am not sure why that happens, but every time I approach a GIS first, rasters is one of the last things to be considered. :-) Also the gvSIG raster system is not the best right now, but I know that there are resources to work on it next year, so I am quite happy about it.

For now, one thing that is really necessary, is the possibility to style rasters properly.

Right now, if I define a colortable for a map, I get 255 color rules.
One good example is the map of aspect. Such a map, that ranges between 0 and 360 degrees, is usually coloured from white to black between 0 and 180, and from black to white between 180 and 360. So all you need would be 3 rules, not 255 which make everything unreadable (apart of being wrong):



If I wanted to customize them, the only way I seemed to have, was selecting and editing each rule. That got odd very quickly.

So it has been better to invest that time to create a small styling tool, which right now is hosted in the HydroloGIS menu, but I really hope it will get into the raster style engine at some point.

An example: One of my favourite base maps is the elevation model with the aspect map overlayed with transparency, which gives that 3D sensation.

Just select the colortable and the transparency. Also the number format pattern in the legend and push apply. That is it:


Some legends are just colors, which will be adapted between the min and max of the raster map. Others, like the map of flowdirections instead, have defined unique values and colours:



One thing I have not been able to, is styling a map with a logarithmic scale. I have tried but failed. That one is for example important for a map like the one of total contributing areas, where the values range from 1 (many many cells) to huge numbers (but few few cells):


well, this should look more like this:


Coordinates Info tool

To exercise myself (and because Silvia forced me to :-) ) I developed a mini-plugin that allows the user to view the clicked coordinates and see them in another projection, but most of all allows to copy them quickly to use them:






Well known text tools

A last small tool that I added is the WKT toolbox. It is a very simple tool, but we find it very useful:



With it you can select a geometry in the layer and extract the WKT representation of the geometry.

The same way, in the lower box, you can write/paste some WKT geometry and it will be inserted as new feature in the currently selected layer, if it is of the same geometry type.

This makes it very easy, for example, to insert points in a layer.


Conclusions

Well, it is strange for me to finish a blog post with a conclusions section, but this one requires it.

I love the open source ecosystem. Once again, even if with much work and some investment, we have been able to find what we needed. HydroloGIS will from now on embrace the gvSIG community and bring its tools (as well as the ones from the universities of Trento and Bolzano) into gvSIG (time and resources permitting).

We have a desktop GIS again. We have a community that focuses on a community GIS again. One that focuses on user needs and tools, on cool selection features, even cooler editing features, on a working printing system (do we want to produce maps or not!??!?!), on 3D, on linear referencing, on table joins, and... and...

Hardhearted I bid farewell to the uDig project. With a small tear in my eyes I say ciao to those great developers with which I shared many nights, code sprints and fun talks. Jody and Frank, it has been a great journey with you and I will see you at the next Foss4g. I know you will bring uDig on top again at some point even without me ;-). Good luck in your quest!  





Wednesday, November 11, 2015

GEOSS2GO project sponsored by the European Commission!

It is several months I do not publish and have at least 4 posts I have to write about arduino, geopaparazzi, gvSIG, uDig... oh my...

I have a good reason though... and that reason is called Simon and is now 8 months old. I don't regret any second I dedicated him instead of this blog.

But what better way to start if not with a great announcement???


This year HydroloGIS decided to participate to the call for innovative apps by the European Commission proposing an app that would exploit the power of geopaparazzi by making it customizable by third party apps.

In the particular case of MYGEOSS it will be possible to create apps that will make selected datasets and surveying forms available using the MYGEOSS data layers.

This will make it possible to use the app to customize the domain of the survey.

Well.... we won!!!!! Together with other 15 we were chosen and sponsored to develop the app!

What is the name of the future app?

As you can see here

GEOSS2GO by Hydrologis S.R.L.
Mobile app for digital field mapping in different domains (tourism, agriculture, risk management).













What is the "call for innovative apps"?

Citing parts of the project's site: The MYGEOSS project launched on September 15th its second open call for innovative applications using open data, or crowd-generated data in different domains that address citizens’ needs. The call closed on the 30th September and was a resounding success with 42 applications received from 15 countries: 43% from SMEs, 36% from universities and research centres, and 21% from individuals.

The submissions were reviewed by an international panel composed by members of staff of the European Commission, European Environment Agency, European Space Agency, European Research Agency, the private sector (OGC and Epsylon-Italia), and the European Citizen Science Association.

This is Open Data and Open Source and benefits also Geopaparazzi, which will be extended to interact with plugin-applications.

Tuesday, June 30, 2015

Geopaparazzi 4.4.0 is out! First RasterLite2 for the brave!

The version 4.4.0 of Geopaparazzi has been pushed to Google Play.


The main news for this release is for sure the first inclusion of RasterLite2, the spatialite raster support, in the release. This makes geopaparazzi 3Mb heavier but it is worth the price.


So to summarize:


1) RasterLite2 support


RasterLite2 is not yet in stable phase, but it is already good to play with. A first stable release should be out by begin of the next year.


For this kudos go to Mark Johnson, that took care of making this possible.


It is also Mark to supply this beatiful map of Berlin in RasterLite2 format:








A RL2 database can contain more than one map, so a review of the tile source tree has been necessary. The RL2 database is represented as folder:







And also the filter-by-type buttons had to be changed because of space issues:



But good thing is, they now remember the last used setting.








2) view the position coordinate when panning



This is a small one, but handy to many. An image explains it all:




3) and last but not least, a better center on GPS button and better GPS status on the map

This has been asked a couple of times in the list, so we thought it might be best to put them together.

Can you tell the difference?



That should be the most important changes for this release!
Enjoy!!






Monday, June 1, 2015

Epl-Gpl discussion from 2011

In 2011, driven by the need to better understand how to make GPL and uDig work together, I wrote an open letter to the Eclipse Foundation and the Free Software Foundation. I collected thoughts and results in the wiki of JGrass. Recently I had to migrate it and found this again. I want to keep it here for reference... and maybe it is also usefull to others.

Mind that this is pretty much a copy/paste of the original wiki page.


 
Here we go:




This wiki page contains informations, email exchanges and useful links regarding the possibility to mix and distribute code licensed under the GPL and the EPL.

Open letter for request of clarification to the Free Software Foundation Europe regarding the coexistence of GPL and EPL licensed code

To gain better understanding of the GPL-EPL compatibility problem, we wrote the following open letter to the Eclipse Foundationd and the FSF.

Introduction

My name is Andrea Antonello and I am an active member of the free and open source software (from now on FOSS) community for years now. I am member of the Open Source Geospatial Foundation (www.osgeo.org) and active developer and steering comittee member in a couple of FOSS GIS projects based on the eclipse rcp (from now on RCP).

For better understanding of the usecases I will ask you clarification of, let me give some introductory explanation.

Eclipse RCP doesn't need much presentation. It is the Rich Client Platform, released under the Eclipse Public License (from now on EPL) and the source of many doubts in licensing issues. uDig is a FOSS GIS and a GIS development kit released under lesser general public license (from now on LGPL). uDig is heavily based on the RCP. JGrass is a set of plugins for uDig and RCP released under LGPL. JGrass is heavily based on the RCP.

It is clear that this situation has no issues, since EPL and LGPL are compatible licenses.

I should mention that in the following cases GPL refers to the GPL version 3.

Motivations

JGrass is a highly scientific project, and as such it has difficulties in exploiting the real power of FOSS, since many scientific project that JGrass could use or connect to are released under general public license (from now on GPL).

This is the reason for which the JGrass team would like to release its plugins under the GPL license.
Given the incompatibility of EPL and GPL, many discussions were raised which lead to lot of confusion and potential border cases that may harm both the project's community and the involved commercial partners.

This letter is meant to request some clarification once and for all by proposing a couple of use cases of development and deployment of the above mentioned applications. I apologize in advance for  having inserted some obviously incompatible cases. The reason for this is that I would like to create a document for the above communities (and not only) to give more clearness and to assure many community members that have had problems with freeing their code to the above RCP based projects.

Use cases

Of the following 5 use cases, the first 4 all assume the following:
I write a simple rcp plugin (from now on called MYPLUGIN) to be used for uDig (for example like explained here). Developed in such a way the plugin contains imports of libraries from both the RCP:
  •  org.eclipse.ui
  •  org.eclipse.core.runtime
and uDig:
  •  net.refrations.udig.project.ui

It is important to note that the MYPLUGIN contains only plugin specific code, which relies on implementations that reside in the referenced packages
  •  org.eclipse.ui
  •  org.eclipse.core.runtime
  •  net.refrations.udig.project.ui
and are present in the target environment (uDig or RCP).

To be clear, in this case import is meant really as the java statement to declare which packages of external libraries shall be used by MYPLUGIN.

Use case one: writing a RCP based plugin and releasing it under GPL

I license MYPLUGIN under GPL, create a small jar archive of MYPLUGIN, put it on a website with installation instructions for putting it into uDig.

Can this be done?

Use case two: writing a RCP based plugin, releasing it under GPL and deploy it as an application

I license MYPLUGIN under GPL, package it with the uDig application, which I brand and bundle in one ready-to-use installer. I then put it on a website where users can download and use it.

Can this be done?

Use case three: writing a RCP based plugin, releasing it under GPL and install it as an application for a customer

I license MYPLUGIN under GPL and put it on a website as in use case one.

Assuming I wrote MYPLUGIN for a customer,  which of the following options are legal?
  •  subcase 1: make a cd with both the uDig application and MYPLUGIN (but separate), and put on the cd installation instructions.
  •  subcase 2: make a cd with uDig incorporating MYPLUGIN within a single installation file.
  •  subcase 3: go to the customer site and install uDig and MYPLUGIN, creating an application ready for the customer's use.

Use case four: writing a RCP based plugin, releasing it under GPL and making it available via the eclipse rcp update site engine

I license MYPLUGIN under GPL.

I want to use the RCP's own installation manager to make MYPLUGIN available to both community and customers.

Can this be done?

Use case five: writing plugins using the Osgi framework


The following use case is a bit different from the above ones.

I want to develop a library based on the framework. Since through the uDig and RCP development I am very bound to the eclipse RCP, I decide to use the  Equinox framework to create the plugins that compose my library (instead of for example Apache Felix, which would have compatible license).

The library I produce will therefore contain imports of the equinox framework.

Which of the below can I do?
  •  subcase 1: I deliver my library and the user will have to download the osgi framework on his own.
  •  subcase 2: I deliver my library packaged together with the osgi framework libraries.

Conclusions


I feel that there is much confusion on the user's part when it comes to certain licenses. The EPL and GPL mixture is a real headache and still I'm not able to find someone that would assure me regarding this topic.

This letter is born of the opinion that a FOSS project comittee has to be able to give clear information about what can and cannot be done to potential developers and investors of the project.


Thanks in advance for the clarifications that the Free Software Foundation can give us.

Warmest regards
Andrea Antonello

on behalf of at least:
  •  the uDig community
  •  the JGrass community
  •  the BeeGIS community
  •  the Java User Group Trentino-Altoadige
  •  and several commercial FOSS based companies

EPL-GPL: the verdict - UPDATE 2010/04

Through the below letter we got several email exchanges directly with the Executive Director of the Eclipse Foundation, Mike Milinkovich, who was very helpful in getting a good picture of what the problems are.

At the time of sending my email, Eclipse Foundation and FSF were discussing the GPL/EPL issue, so I didn't get a direct answer to the questions in the open letter, but now there is a public answer about the issues available:

 

Comments and conclusions

After long discussions we think that the following applies:
  •  it is not possible to create a pure GPL eclipse plugin. That makes one wonder why so many exist in the eclipse marketplace...
  •  since an eclipse plugin is compatible only in the case in which an exception is added to the license (remember the classpath exception?)
  •  and to create such an exception every author involved in the linked code has to agree on the exception
  •  also because derived works inherit the license together with the exception, which basically is what the FSF states in the last part of its blog post: "...can address this issue by providing an additional permission with their license that grants users permission to combine their work with Eclipse in this way..."



Wednesday, April 29, 2015

Geopaparazzi 4.3.0 is out!

A new Geopaparazzi version 4.3.0 has been pushed out in google play.


A quick release note:


1) The routing service has been replaced
The OpenRoutingService didn't work any more lately and I found the nice OsmBonuspack that had code for OSRM, MapQuest and Graphhopper, so I decided to adapt it to work in geopap and have those 3 options.


For both MapQuest and Graphhopper you will need to register to their website and ask for an API-KEY. That key can be inserted in the Geopaparazzi settings. If no key is available, those two routing services will not appear in the available services choice list.





2) Export images


Since we passed to the single project file format people wanted to export the images. We now added that option in the export menu.








3) Ability to change the language from within Geopaparazzi


This has been asked by one of the translators, and since we love our translators, we added that option (Force Locale) in the settings:


You can choose between the languages supported for Geopaparazzi:


After that, each newly loaded view will be in the new locale, as for example here in Japanese:


4) Bugfixes and small enhancements



  • it is now possible to open the image from its thumbnail embedded in complex forms
  • use of OpenStreetMap links in all places where position is shared
  • fix for forms that were not saved from the notes list view
  • fix for folders based mapurls that were not shown
  • fix for crash when accessing the secret view
  • fix for crash on kmz export

 Enjoy!!!







Wednesday, February 25, 2015

Geopaparazzi 4.2.0 is out: never out of data in the field

When I got that odd issue on the tracker about the GPS azimuth value not being properly handled in Geopaparazzi, I didn't think that this release would have any new feature. But well, once you sit down to fix things, you see things... and once you see thing, you want things :-)

First off, some bugs should be now fixed:
  • notes halo is ignored 
  • mapview doesn't render points and tracks when returning from standby
  • while downloading remote tiles sometimes the dashboard freezes 
  • azimuth should be only one: this is a big one, since now we the azimuth is always calculated properly and when a picture is taken it will be the right one.
  • geopap sometimes crashes when taking pictures
And that is already nice, particularly the azimuth one.

But here comes the Boom:

OSM data extraction from mapsforge tiles in offline mode


The mapsforge tiles are generated on the device from a particular vector format. This means that there are information available in the database. Problem is that, very very simply put, the information contained is extracted differently at different zoom levels, because in fact the library and the format have been done that way to allow rendering performance.

But still it is possible to extract almost everything we see, which is nice.

Let's see how this works. Assume you have a job to do, are out in the field and want view information overlayed on the ortofoto pictures from the local WMS service.

Well, the map file you get from mapsforge looks like the following:


Now go in the mapvieW menu and you will find a new entry: Import mapsforge data


The import view will appear:


From the view you can see that 2 types of data can be imported: points and ways.

Points

Since the points are often visible on a different zoomlevel then the current, also 3 zoomlevels below the current are investigated to extract data and double points are not considered. So if you start this at zoomlevel 16, you will also get 17, 18, 19. Since the same are at a different zoomlevel will have many more tiles, about 10000 tiles are read to import the data.

You can add a filter text to import only tags containing a given text or exclude all those containing the text.

Points are imported in the current projectdatabase and saved as forms notes containing all the values Openstreetmap has. As such they can also be edited.


Ways

Many types of ways are stored in the mapsforge map files and many of them are actually related to areas.

The user can choose to import:
  • ways: roads, railways, cableways and similar
  • waterways: lines that represent water
  • contours: contour lines if they are available
Since these data are heavy, the data are imported into a spatialite database.
This brings up a new issue: since this release a database for mapsforge extracted data is automatically created if there is none present. You will find a database named mapsforge_extracted.sqlite always present in your maps folder. And you will find 3 layers always present in the spatialite data layers: osm_waterlines, osm_roads and osm_contours.



But let's get back to import the data. Just select the data you want to import and push the start button. In the case you selected all data types, you should see first an import dialog like this:


and then something like this:


Nice ha? :-)
Depending on what has been imported first, the labels might not be coming from the right field. In that case you can simply change the label in the spatialite layer settings.

Before we look into it, let's see what happens in the case we use a map that also shows contour lines. To do so, we want to clear those layers. The fastest way to do so is to simply delete the mapsforge database and let geopap recreate it.
So after doing so and loading a map with contours I will have the same region as:



If you now import everything available exactly as before, you will get:


To have a better idea, change the background map to something different. I also change the contours color to white:






Label support is not advanced, so they get readable only once you zoom in:




That is quite cool ha? All from offline data!!

You now might wonder why all imported notes have a (MF) in their name. That is done so one can quickly select and remove them. Believe me, that is a feature you want to have. The region I am showing you has few points and already around 50 notes have been imported. In towns this is exponential.

This anyways brings us to the next point:

Enhancement of notes handling

While working on this, I noticed that when importing notes, all my notes got hidden in the mass of imported notes. Also, many of the imported notes are POIs that I do not care about (ex. benches, towers, etc).

The current notes list didn't have the tools to handle this. So how does it work now?
Enter the new notes list:


This is how it looks like after the previous import. Somewhere there is also a note I created manually "My tiny note".

As you can see, notes can now be selected (checkbox on left). You can zoom to the note as before and all other icons are now in the last one on the right side.

If you tap it, you get a context menu:


  • Edit: as before it allows you to edit a note if it is a form note and view image notes
  • Share: share the note in social networks
  • Delete: delete the note
  • Use as selection: this gives the possibility to select only those notes that have the same name as the one used to pop the menu
  • All notes: opens a submenu for actions that apply to all notes
 Lets assume I want to remove all bus stops. I select the menu on any of the bus stops and tap on the Use as selection.

Only the bus stops will be visible and selected:






Now access the All notes menu:





well, it is quite clear what to do. Delete all selected.


What if I want to remove all mapsforge notes? Insert (MF) in the filter text and remove all selected.

Last but not least, with all this spatialite fiddling, a big help has been added for vector editing.

Import a template spatialite database

If you go in the import section, you will find a new entry: Default Database.

When hitting that, you are asked to name the new database to create, let's use testdb for the sake of this example.






Now you will have to restart geopap, sadly that is still required. One it is done, go in the spatialite database view. 3 new layer of the database testdb.sqlite will be visible:






While lines and points won't be of much use in geopap yet, you will find the polygon layer interesting, since it is editing ready. Enable editing and edit right away. Since it is a template db, the attributes table has been created as 20 fields with names from field1 to field10. As said, very simple, but in my opinion still of use when you have to quickly collect some polygon data with attributes.






That is all for this release... enjoy!!!