Hi devs,
I study geoinformatics at CTU in Prague and I get interested in some of your topics for GSoC. I have basic knowledge in C/C++ and I’ve already written some code in Python for GRASS Add-Ons.
I’d like to focus on Mapnik engine, actual display drivers and graphic outputs.
Let me know if this topic is still free to pick-up and what I shlould do for the next step.
Thanks.
Adam Laza
On Mon, Mar 9, 2015 at 10:37 AM, Adam Laža <ad.laza32@gmail.com> wrote:
Hi devs,
I study geoinformatics at CTU in Prague and I get interested in some of
your topics for GSoC. I have basic knowledge in C/C++ and I've already
written some code in Python for GRASS Add-Ons.
I'd like to focus on Mapnik engine, actual display drivers and graphic
outputs.Let me know if this topic is still free to pick-up and what I shlould do
for the next step.
Welcome, for start, could you please link here all your contributions so
that we don't have to search for it?
As far as I know, the topic is still free.
Cheers,
Anna
Thanks.
Adam Laza_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
I worked on natural neigbour interpolation and I wrote v.surf.nnbathy and r.surf.nnbathy modules in Python [1]. These modules are dependent on external libraries nn-c and Triangle. For my bachelor thesis I try to get rid of the dependencies and use existing modules v.delaunay and v.voronoi instead.
Adam
[1] http://trac.osgeo.org/grass/browser/grass-addons/grass7/misc/m.surf.nnbathy?rev=63441
2015-03-09 17:02 GMT+01:00 Anna Petrášová <kratochanna@gmail.com>:
On Mon, Mar 9, 2015 at 10:37 AM, Adam Laža <ad.laza32@gmail.com> wrote:
Hi devs,
I study geoinformatics at CTU in Prague and I get interested in some of your topics for GSoC. I have basic knowledge in C/C++ and I’ve already written some code in Python for GRASS Add-Ons.
I’d like to focus on Mapnik engine, actual display drivers and graphic outputs.Let me know if this topic is still free to pick-up and what I shlould do for the next step.
Welcome, for start, could you please link here all your contributions so that we don’t have to search for it?
As far as I know, the topic is still free.
Cheers,
Anna
Thanks.
Adam Laza
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
2015-03-10 8:09 GMT+01:00 Adam Laža <ad.laza32@gmail.com>:
I worked on natural neigbour interpolation and I wrote v.surf.nnbathy and
r.surf.nnbathy modules in Python [1]. These modules are dependent on
btw, it's old link, the modules have been moved to [1,2]. Martin
[1] http://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.surf.nnbathy
[2] http://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.surf.nnbathy
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
Hi Adam,
2015-03-09 15:37 GMT+01:00 Adam Laža <ad.laza32@gmail.com>:
I study geoinformatics at CTU in Prague and I get interested in some of your
topics for GSoC. I have basic knowledge in C/C++ and I've already written
some code in Python for GRASS Add-Ons.
I'd like to focus on Mapnik engine, actual display drivers and graphic
outputs.
great! The proposal on the wiki [1] is somehow focused on writing
alternative rendering engine for ps.map [2] which is currently used by
wxGUI Cartographic Composer [3]. It would be probably a good idea also
to investigate whether would be possible to write a new GRASS display
driver [4] based on Mapnik libraries. In other words replacement for
Cairo [5] driver focused on cartographic outputs. Such driver would be
written in C and would require C-API for Mapnik, I found something on
[6], but I am not sure if it would be possible to use.
Martin
[1] http://trac.osgeo.org/grass/wiki/GSoC/2015#MapnikrenderingengineforGRASSGIS
[2] http://grass.osgeo.org/grass70/manuals/ps.map.html
[3] http://grasswiki.osgeo.org/wiki/WxGUI_Cartographic_Composer
[4] http://grass.osgeo.org/grass70/manuals/displaydrivers.html
[5] http://grass.osgeo.org/grass70/manuals/cairodriver.html
[6] https://github.com/springmeyer/mapnik-c-api
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
On 9 March 2015 at 15:37, Adam Laža <ad.laza32@gmail.com> wrote:
Hi devs,
Hi Adam,
I study geoinformatics at CTU in Prague and I get interested in some of your
topics for GSoC. I have basic knowledge in C/C++ and I've already written
some code in Python for GRASS Add-Ons.
I'd like to focus on Mapnik engine, actual display drivers and graphic
outputs.
cool!
Let me know if this topic is still free to pick-up and what I shlould do for
the next step.
I think it is still free, nobody wrote in the mailing list
Thanks.
Adam Laza
--
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
On 10 March 2015 at 09:47, Martin Landa <landa.martin@gmail.com> wrote:
Hi Adam,
Hi Martin,
2015-03-09 15:37 GMT+01:00 Adam Laža <ad.laza32@gmail.com>:
I study geoinformatics at CTU in Prague and I get interested in some of your
topics for GSoC. I have basic knowledge in C/C++ and I've already written
some code in Python for GRASS Add-Ons.
I'd like to focus on Mapnik engine, actual display drivers and graphic
outputs.great! The proposal on the wiki [1] is somehow focused on writing
alternative rendering engine for ps.map [2] which is currently used by
wxGUI Cartographic Composer [3]. It would be probably a good idea also
to investigate whether would be possible to write a new GRASS display
driver [4] based on Mapnik libraries. In other words replacement for
Cairo [5] driver focused on cartographic outputs. Such driver would be
written in C and would require C-API for Mapnik, I found something on
[6], but I am not sure if it would be possible to use.
Good Idea to create a new driver based on Mapnik 
I never heard about the C-API for Mapnik but they should be useful. I
could ask to Dane what is the stability of the C-API.
Is there any way to write the driver in Python (the Mapnik Python API
are probably more stable, used and tested than the C-API)
Martin
--
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
On Tue, Mar 10, 2015 at 4:56 AM, Luca Delucchi <lucadeluge@gmail.com> wrote:
On 10 March 2015 at 09:47, Martin Landa <landa.martin@gmail.com> wrote:
> Hi Adam,
>Hi Martin,
> 2015-03-09 15:37 GMT+01:00 Adam Laža <ad.laza32@gmail.com>:
>> I study geoinformatics at CTU in Prague and I get interested in some of
your
>> topics for GSoC. I have basic knowledge in C/C++ and I've already
written
>> some code in Python for GRASS Add-Ons.
>> I'd like to focus on Mapnik engine, actual display drivers and graphic
>> outputs.
>
> great! The proposal on the wiki [1] is somehow focused on writing
> alternative rendering engine for ps.map [2] which is currently used by
> wxGUI Cartographic Composer [3]. It would be probably a good idea also
> to investigate whether would be possible to write a new GRASS display
> driver [4] based on Mapnik libraries. In other words replacement for
> Cairo [5] driver focused on cartographic outputs. Such driver would be
> written in C and would require C-API for Mapnik, I found something on
> [6], but I am not sure if it would be possible to use.
>Good Idea to create a new driver based on Mapnik
I never heard about the C-API for Mapnik but they should be useful. I
could ask to Dane what is the stability of the C-API.
Is there any way to write the driver in Python (the Mapnik Python API
are probably more stable, used and tested than the C-API)
Adam, Luca and Martin, I agree that the cartography in GRASS GIS is limited
and I always like the idea of using another project to do the hard work for
us. However, as I see the discussion here, I would recommend you to be more
specific about the advantages, disadvantages and possible implementation of
this proposal.
For the idea itself, how it would work with Mapnik dependency once it is
implemented especially if the dependency would be through C API? What are
the chances that it will be actually used. I have in my mind that there are
still problems with Cairo on MS Windows and until recently one had to often
use PNG driver on MS Windows.
Speaking about ps.map + Cartographic Composer versus display drivers + Map
Display, I prefer the latter and I think we should specify our priorities.
If I need to start another application (or window), I can also start, for
cartography purposes, completely different application such as QGIS. Then
GRASS-QGIS connection is the think which should be improved.
QGIS map composer also has Python API if I remember correctly and it is
highly probable that one has both GRASS GIS and QGIS installed.
It is not out of interest that there was a Mapnik plugin for QGIS [1] but
it is no longer maintained [2] (ended before version 2.0 [3]).
Adam, you should also notice not only that more students can apply for one
project (idea) but also that one student can submit multiple applications
for different projects.
Best,
Vaclav
[1] http://plugins.qgis.org/plugins/quantumnik/
[2] https://github.com/springmeyer/quantumnik/commits/master
[3] http://plugins.qgis.org/plugins/quantumnik/version/0.4.1/
> Martin
>--
ciao
Lucahttp://gis.cri.fmach.it/delucchi/
www.lucadelu.org
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
2015-03-10 9:47 GMT+01:00 Martin Landa <landa.martin@gmail.com>:
driver [4] based on Mapnik libraries. In other words replacement for
Cairo [5] driver focused on cartographic outputs. Such driver would be
btw, Mapnik is using Cairo as one of renderers [1]. Martin
[1] https://github.com/mapnik/mapnik/wiki/MapnikRenderers
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
I was thinking about this a little bit and I still don’t see what would be the advantages of Mapnik over other solutions and how used would be the result considering that the GUI would be still quite limited. For me it seems that if I need some basic outputs, map display with cairo is fine especially if we would have some more improvements [1]. If I need advanced cartography I have to go to QGIS or something like Mapnik or GMT.
The idea of using Mapnik as common OSGeo cartographic backend seems dead [2] but perhaps QGIS is here to take this place.
Or do you see this also a something like a missing GUI for Mapnik where one could generate just some configuration file which could be later used somewhere else with Mapnik?
Yet another direction is Matplotlib [4] which is anyway a dependency. But perhaps this would be just another simple backend which is more advantageous when used as part of API. There was actually an attempt co couple GRASS GIS with Matplotlib map rendering [5].
Just my thoughts,
Vaclav
[1] http://trac.osgeo.org/grass/wiki/GSoC/2015#CompletebasiccartographysuiteinGRASSGISwxGUIMapDisplay
[2] http://wiki.osgeo.org/wiki/OSGeo_Cartographic_Library
[3] http://docs.qgis.org/2.6/en/docs/pyqgis_developer_cookbook/composer.html#output-using-map-composer
[4] http://matplotlib.org/basemap/users/examples.html
[5] http://lists.osgeo.org/pipermail/grass-dev/2013-October/066017.html
On Tue, Mar 10, 2015 at 2:07 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2015-03-10 9:47 GMT+01:00 Martin Landa <landa.martin@gmail.com>:
driver [4] based on Mapnik libraries. In other words replacement for
Cairo [5] driver focused on cartographic outputs. Such driver would bebtw, Mapnik is using Cairo as one of renderers [1]. Martin
[1] https://github.com/mapnik/mapnik/wiki/MapnikRenderers
–
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On 12 March 2015 at 05:38, Vaclav Petras <wenzeslaus@gmail.com> wrote:
I was thinking about this a little bit and I still don't see what would be
the advantages of Mapnik over other solutions and how used would be the
result considering that the GUI would be still quite limited. For me it
seems that if I need some basic outputs, map display with cairo is fine
especially if we would have some more improvements [1]. If I need advanced
cartography I have to go to QGIS or something like Mapnik or GMT.
But we could integrate Mapnik inside GRASS, it has a lot of feature
for printing beautiful maps
The idea of using Mapnik as common OSGeo cartographic backend seems dead [2]
but perhaps QGIS is here to take this place.
I'm sorry about that, I like this idea, never heard about that.
Or do you see this also a something like a missing GUI for Mapnik where one
could generate just some configuration file which could be later used
somewhere else with Mapnik?
No, my idea was to use Python API to add Mapnik backend to the
Cartographic Composer, Martin proposed to use the C-API to add another
graphical driver.
Yet another direction is Matplotlib [4] which is anyway a dependency. But
perhaps this would be just another simple backend which is more advantageous
when used as part of API. There was actually an attempt co couple GRASS GIS
with Matplotlib map rendering [5].
Yes this could be another direction, I proposed Mapnik because I use
it and I like it.
Just my thoughts,
Vaclav
--
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
On Thu, Mar 12, 2015 at 7:07 PM, Luca Delucchi <lucadeluge@gmail.com> wrote:
> Or do you see this also a something like a missing GUI for Mapnik where
one
> could generate just some configuration file which could be later used
> somewhere else with Mapnik?
>No, my idea was to use Python API to add Mapnik backend to the
Cartographic Composer, Martin proposed to use the C-API to add another
graphical driver.
What I mean is that the by using Mapnik as a backend for Cartographic
Composer (CC), you are essentially creating a GUI for Mapnik. So perhaps if
you add few generalizations, CC could be used in this way.
And on a similar note, although Mapnik would be backend for CC or another
display driver, CC, Map Display, display library and d.* modules lack the
proper interface to use Mapnik's (advanced cartographic) features. For
example, if Mapnik can do the nice roads with outline where on a crossroad
there is no outline crossing, we have to have an interface to set the
outline and also display library (general/abstract display driver API) has
to handle the crossroad differently (just guessing here). Well, it would be
great to have these features.