Re: [JPP-Devel] new SaveAs wizard

2016-07-29 Thread Giuseppe Aruta 
hi Stefan
.asc and .felt can have a .prj file. Regarding raster I also found
something similar (file.jpg -》file.jpg.prj)
Il 29/Lug/2016 16:41, "Stefan Steiniger"  ha scritto:

> > which formats actually depend on a prj file because they don't file
> their projection themselves?
> as far as I recall its only shapefile ;) There aren't many other
> standard vector formats.
> Interestingly QGIS creates sometimes in parallel a *.qpj file, not
> touching the original one.
> In geojson there is only definition of the projection as epsg code ¿I
> think?, not as separate file.
>
> And for raster we have only tfw - but this doesn't include the
> projection/coord sys info. Interestingly I got recently data where they
> send me also a prj file with the raster data... so one would know which
> projection it is in.
>
> my 2 cents,
> stefan
>
>
>
> --
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] new SaveAs wizard

2016-07-29 Thread Stefan Steiniger 
> which formats actually depend on a prj file because they don't file their 
> projection themselves?
as far as I recall its only shapefile ;) There aren't many other 
standard vector formats.
Interestingly QGIS creates sometimes in parallel a *.qpj file, not 
touching the original one.
In geojson there is only definition of the projection as epsg code ¿I 
think?, not as separate file.

And for raster we have only tfw - but this doesn't include the 
projection/coord sys info. Interestingly I got recently data where they 
send me also a prj file with the raster data... so one would know which 
projection it is in.

my 2 cents,
stefan


--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] new SaveAs wizard

2016-07-29 Thread edgar . soldin 
On 29.07.2016 16:10, Giuseppe Aruta wrote:
> Hi Ede,
> Excuse me  for long time to answer. I am still on Bolsena Lake with poor web 
> connection . I will test the New Save wizard in the next week when I am back 
> home and give back a feedback.

looking forward to it

> I follow the discussion and read Michael's questions/your answers.
> I was planning after vacation to add an extra plugin on layer context menu, 
> which will save layer projection to .prj file ( it requires a .prj codes 
> registry that I have and doesn't occupy too much space). My original idea was 
> to add this function as saparate plugin untill i would have studied to use it 
> as option on save shapefile(*).

which formats actually depend on a prj file because they don't file their 
projection themselves?

> But I think I could try to implement this function as a separate writer on 
> SaveWizardPlugIn ( with enablecheck). I will study your code. I suggest also 
> to put few notes and a sample, when ready,  on a wiki page.

as it is not a dataset but metadata about it i'd say you should implement a 
PrjFileWriter that wraps the common data writer classes in OJ and hence 
automagically writes a prj file everytime the format is written itself.

..ede

--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] new SaveAs wizard

2016-07-29 Thread Giuseppe Aruta 
Hi Ede,
Excuse me  for long time to answer. I am still on Bolsena Lake with poor
web connection . I will test the New Save wizard in the next week when I am
back home and give back a feedback.
I follow the discussion and read Michael's questions/your answers.
I was planning after vacation to add an extra plugin on layer context menu,
which will save layer projection to .prj file ( it requires a .prj codes
registry that I have and doesn't occupy too much space). My original idea
was to add this function as saparate plugin untill i would have studied to
use it as option on save shapefile(*).
But I think I could try to implement this function as a separate writer on
SaveWizardPlugIn ( with enablecheck). I will study your code. I suggest
also to put few notes and a sample, when ready,  on a wiki page.
Best regards
Peppe

(*)
Also save SLD style should be implemented as an option on  shapefile writer
or on save to vector writers


Il 28/Lug/2016 11:21,  ha scritto:

>

> >

> On 27.07.2016 23:53, Michaël Michaud wrote:
> > Hi Ede,
> >
> > I'm tying to add database writer to the new SaveWizardPlugIn.
> >
> > I added a SaveToDataStoreWizard in the initialize method of
SaveWizardPlugIn,
> > So far so good (it does not do anything yet ;-)
> >
> > In SaveWizardPlugIn execute method, I see that inputData is referenced
under the key
> > SaveFileWizard.DATAKEY_LAYERNAME
> >
> > Should I change it to
> >
> > SaveWizardPlugin.DATAKEY_LAYERNAME as SaveWizardPlugin should not
depends
> > on a particular wizard ?
>
> sounds reasonable to me :)
>
> > Also I think that the normalization of layerName should be handle by
each wizard
> > as the rule may be different for a filename and for a tablename.
>
> it's intended as an optional input for savewizards to use or not. i like
to have a central place that generalizes the layername in a way that most
savers could use.
>
> >And maybe
> > multiple layer should be accepted at this stage, some wizards may be
able to
>
> yeah, no.. let's keep it simple for now and focus on saving one layer as
...
>
> > handle several layer...
>
> maybe at a later stage, but essentially i think that this needs another
plugin alltogether, maybe using components of this one.
> more details coming in the answer to your other email.
>
> ..ede
>
>
--
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net

> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


Il 28/Lug/2016 11:21,  ha scritto:
>
> On 27.07.2016 23:53, Michaël Michaud wrote:
> > Hi Ede,
> >
> > I'm tying to add database writer to the new SaveWizardPlugIn.
> >
> > I added a SaveToDataStoreWizard in the initialize method of
SaveWizardPlugIn,
> > So far so good (it does not do anything yet ;-)
> >
> > In SaveWizardPlugIn execute method, I see that inputData is referenced
under the key
> > SaveFileWizard.DATAKEY_LAYERNAME
> >
> > Should I change it to
> >
> > SaveWizardPlugin.DATAKEY_LAYERNAME as SaveWizardPlugin should not
depends
> > on a particular wizard ?
>
> sounds reasonable to me :)
>
> > Also I think that the normalization of layerName should be handle by
each wizard
> > as the rule may be different for a filename and for a tablename.
>
> it's intended as an optional input for savewizards to use or not. i like
to have a central place that generalizes the layername in a way that most
savers could use.
>
> >And maybe
> > multiple layer should be accepted at this stage, some wizards may be
able to
>
> yeah, no.. let's keep it simple for now and focus on saving one layer as
...
>
> > handle several layer...
>
> maybe at a later stage, but essentially i think that this needs another
plugin alltogether, maybe using components of this one.
> more details coming in the answer to your other email.
>
> ..ede
>
>
--
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel