Hi Andrei, SVG users
There's a major improvement in the quality of the SVG output. Hmm, for
topologically accurate SVG exports I think the resolution should be
determined by the smallest distance between 2 vertices in the dataset.
If this cannot be done or is too complicated to implement, than I'm
perfectly fine with a 0.1 pixel resolution. No need to go below 0.1 in
my opinion.
Setting a higher resolution is not a technical problem. It is a
precision vs file size tradeoff.
My reasonning is :
SVG is for graphic output not for topological computation.
If someone needs to print a 40 cm OpenJUMP map (screen size) to a 100 cm
paper sheet with a 0.1 mm resolution (high quality printing), he will
need a
resolution which is 7 times higher than the screen resolution.
==> 0.1 should be OK for most application
More may make output file bigger for no use.
But you are the end user, so if you think 0.01 or 0.001 is better, there
is no problem.
Full (data) resolution is also possible, but from my point of view, it
makes no sense,
except if you just need to keep original data unmodified for further
utilization (if you
need to export your data back to a GIS after modification for example).
Michaël
Well, the scaling problem looks serious. Perhaps you should also talk
to Geoff about this. The Printer plug-in PDF export is the only option
to have a final map at the right scale. All the other exports need
additional resizing to the outputs.
Thank you,
Andrei
------------------------------------------------------------------------
*From:* Michaël Michaud <michael.mich...@free.fr>
*To:* Andrei Nacu <andreina...@yahoo.com>
*Sent:* Wednesday, March 27, 2013 9:28 PM
*Subject:* Re: OJ question
Hi Andrei,
Don't worry, I have no intention to hurry you up :)
I know you are working during your freetime and there are many other
things which need to be fixed for the 1.6.0 release. As a volunteer
for OSGeo I thank you for all the work you are doing.
I was curios if you were progressing on the SVG issue because my next
seminar will be on April 12. I have to decide if I will include a
section about exporting a complex map as SVG, and this depends on
fixing the SVG generalization bug (the bug is more visible on
detailed datasets). Secondly, I thought it's very simple to remove
the generalization effect.
I just changed the resolution of the output.
Currently it is determined by the pixel size (screen rendering
resolution = 0.5 pixel).
For svg output I changed it to 0.1 pixel.
I can change it to less than 0.1 pixel, but it may have bad effects on
file output size.
This is available in r3415
Let me know if it is better for you and what you think about keeping a
0.1 resolution.
About scale, I just measured a dataset on my screen and found that the
scale is not right.
Must have a deeper look.
Michaël
Okay, here's my comparison between the exporting options:
First of all, my system display slightly reduces the size of the OJ
project view. Meaning that a scale bar for a map at scale 1:100 000
has about 4,5 cm instead of 5 cm(=5 km). When using Inkscape, for
example, I can apply a zoom correction factor of 118% to obtain a
correct 1:1 scale project view.
1. Open JUMP export
I know we discussed some time ago about scaling issues. This is just
a note now, as my issue is primarily with the generalization problem.
* Scaling. An exported SVG map is slightly bigger than it should
be. I'm not sure if this is system-depending or standard. In the
case of a 100K map the scale bar is 5,362 cm. So, a re-scaling to
93% would be needed to the SVG file.
* Generalization. Happens usually for nodes which are very close
one to another (below 0,1 cm in the project view). It's very
noticeable when you have detailed polygon networks to export.
2. Printer plug in
* Scaling. The scale of an exported SVG map (but not PDF) is 80%
its normal size. A scale bar for a 100K map is 4 cm instead of 5.
* Generalization. There's no difference from Open Jump export when
using the ISA renderer. The Core renderer produces a raster and
the External renderer applies massive generalization.
3. Print layout plug in
I receive an error when I try to insert the map into the printer view:
com/vividsolutions/jts/simplify/DouglasPeukerLineSimplifier (Illegal
Access Error)
I hope this helps. Regards,
Andrei
------------------------------------------------------------------------
*From:* Michaël Michaud <michael.mich...@free.fr>
<mailto:michael.mich...@free.fr>
*To:* Andrei Nacu <andreina...@yahoo.com> <mailto:andreina...@yahoo.com>
*Sent:* Monday, March 25, 2013 9:51 PM
*Subject:* Re: OJ question
Hi Andrei,
I am currently rewriting the presentation for my next Open Jump
seminar and I was curios if you have tackled the SVG driver issues.
I would like to include a small part about exporting vector SVG maps
from Open Jump and working with them in Inkscape, but I feel the
topological errors (generalized polygons and lines) that come with
the SVG file are an impediment. A colleague of mine is doing
something very similar as part of his QGis seminar, and I would like
to show that Open Jump is likewise compatible with Inkscape. I could
even go further and show how to recycle data from a SVG document;
first saved as dxf from Inkscape and then readjusted in Open Jump
using the Warping tools.
A couple of weeks ago I added a feature request for removing the
vector generalization effect on exported SVG files, but it might
actually be a bug. I know you might be having other development
priorities instead, but I would be most thankful if you could move
this issue up on your OJ 'to do' list :)
Sorry if I did not progress on this topic. You surely now that all
the work is done on my freetime and that there is much to do these
days to fix every think which needs to be fixed before 1.6 release.
Moreover, rendering and svg are not domains where I'm an expert, and
it will probably took me some time to take care of this.
By the way, have you ever seen that there are 3 ways to export SVG
- OpenJUMP export
- PrinterPlugIn (cadplan)
- PrintLayoutPlugin
(http://jump-pilot.svn.sourceforge.net/viewvc/jump-pilot/plug-ins/)
I would be interested by a comparison between these tools.
I think the root of the problem is that OpenJUMP uses a
simplification algorithm to print to screen efficiently,
and the image exporter probably re-use the routine which prints to
screens.
I know that PrinterPlugIn has several rendering engines, so there is
a little chance that one of them does not
apply the simplification.
Regards,
Michaël
Best wishes,
Andrei
------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
