On Mon, Jan 23, 2006 at 09:04:18PM +0100, Armin Burger wrote:
> Silke,
>
> I wanted to answer your 2 mails in one, but it began to become a huge
> mail, so I split it up...
This has been the reason why I did sent two emails as well.
>
>
> Silke Reimer wrote:
> >
> >During the projects we had to enhance p.mapper in some directions
> >and I would like to give them back to p.mapper as far as this is
> >possible and useful. Right now I have a great diff (based on version
> >1.9.1 or p.mapper) which I have to split into different diffs for
> >each change. I hereby would like to ask you whether there is interest
> >in our enhancement and which I should prepare as seperate diff:
> >
>
> The problem is that the current development version went quite away from
> version 1.9.1 so that an ingestion of the code cannot be so easily
> achieved, I fear. In general, I would recommend that if somebody wants
> to contribute some parts it might be best to announce something
> beforehand. I would then not touch those parts, or at least try to
> communicate necessary changes that might interfere with the development
> of others. A CVS maybe might help for distributed development, but it
> still would require that developers are aware of what others are doing.
Yes, you are right. BTW: We already contacted you last summer
(before this list existed) but never got an answer. Please don't
misunderstand: This is not an offence since I know the problem of
getting to many emails! It is just an explanation why we contact you
so late.
>
> My general question is, which functionality should find it's way into
> the generic p.mapper without overloading the application with
> if/then/else checks. And which is a very customized add-on that is
> defined for a very special application scope.
>
>
> >Legend:
> >- new legend type multi which is a special combination of some other legend
> > types:
> > - list of all layers
> > - layer out of actual scale are greyed
> > - nested layers
> > - activation/deactivation of layers by checkbox
> >
>
> I think parts of your display methods are available in 1.1.0 and the dev
> snapshot of pmapper 2. But I started now to try a complete new approach
> because especially for version 2 the used JS library 'dTree' has some
> shortcomings. With regard to dynamically added layers (like for
> client-side WMS) there is a need for the possibility to modify the layer
> structure by using the simple functionality of
> [DOM-Object].innerHTML = ''
>
> I experienced strange behaviours for this with dTree and IE for the
> initial loading that may cause the legend to just load partially legend
> icons, and that looks a bit odd. Additionally, the code started to
> become difficult to maintain, because it was spread over different
> functions for each legend/TOC type.
>
> The new approach planned for 1.1.1 and 2.0 is a bit less sophisticated
> using a table structure created by PHP, but it's easier to maintain.
> Also one function should cover all the legend types. The legend/TOC
> types are also more easy to combine. I hope I will find time to get a
> good prototype ready in the next 1 to 2 weeks. I think it might be a bit
> too detailed to describe all the planned legend modes, but for the
> interested folks I can describe it separately.
OK. Since our changes to the legends are rather special I think we
should drop this.
>
> >I18N:
> >- full support for gettext instead of the p.mapper internal way to
> > define text strings.
> >
>
> I already mentioned this in a previous mail. I will use a neutral
> function _p() that can be mapped to the gettext _() or can use the
> current approach. I personally will not use the gettext functionality
> but prefer the maintenance of all language settings via a SQLite DB.
Could you explain why? In my opinion there is no need to implement
an own infrastructure when gettext already has made this.
But anyway: Of course your suggestion is OK. I will than prepare the
patch and send those gettext-files that we have already prepared to
you.
>
>
> >Checkscale:
> >- adaption of minscale and maxscale: p.mapper shows everything in
> > ]maxscale,minscale[ while UMN MapServer works with
> > [maxscale,minscale]. P.mapper has been adapted to UMN MapServer
> >
>
> I do not understand that. I thought pmapper displays all layers that
> have their scale inside the range defined by max/minscale, like
> Mapserver does.
We experienced a different behaviour as described above. Indeed this
is a rather small fix.
> >Info-Results
> >- adding vertical tabular to show results of a layer. This is useful
> > if you many attributes in a tabular but only few results.
> >
>
> How is that achieved? The query result is currently written as
> hard-coded HTML table that makes it difficult to display the result in a
> different way without re-structuring the code. Can you swap between the
> display methods? An approach could be to use something like templates
> (PHP templates, XML and XSL, etc), all with it's advantages and
> disadvantages.
We wrote a new class VQuery which displays the table vertially. It
has indeed been a littly tricky to get the HTML-snappets into the
right order but it still is feasable.
In the mapfile you can define by a new metatag, whether the results of
a layer should be horizontal or vertical aligned. So you could even
have vertical or horizontal tables are possible. If this metatag is
not used, a default value ("horizontal") is applied.
>
> >startGroups and defGroups
> >- we added the parameter startGroups to config.ini which defines
> > those layers which are shown when loading the application the
> > first time while defGroups are now those layers which are shown
> > all the time.
> >
>
> I currently maintain layers that are always to be displayed by not
> mentioning them in the config.ini and set them to STATUS default in the
> map file. How should such layers be displayed in the legend or TOC?
> Without checkbox? Or just in the legend, not in the TOC?
Those layers are not shown in the legend at all. I don't remember
very well but I think we had some problems with just defining those
layers with STATUS default in the mapfile. I should perhaps test
again.
>
> >searchlist:
> >- Define searchlist in a seperate file (mainly because the list has
> > been quite long in our case and will change from time to time)
> >
>
> In newer versions all attribute search definitions are defined in
> 'js_custom.php'. This file is also the area for further customizations
> that should not be touched by newer developments of p.mapper.
Yes, but we thought that js_custom.php should contain the
functionality while all application specific values (such as
concret search places) should be in the config-directory. In my
opinion this is easier to maintain for the application admin since
he has only one directory which contains every configuration.
>
> >Funktions:
> >- added a new function to Show coordinates at a point defined by a
> > mouse click.
> >
>
> Do you mean with display of different projections? Like having the map
> in a Transverse Mercator but the coordinates in lat/lon? Or display both
> projected and geographic coordinates together? The current coordinates
> of the mouse in map coordinates are already available via the
> showCoordinates() function. Or do you think more about displaying the
> coordinates for later copy&paste? I think a generic solution could be
> helpful where you can specify all desired projections as ESPG code and
> get the results back for the mouse click for all of them.
>
> I found it very convenient to have the map displayed in a projected
> system but the coordinates dynamically (for the mouse move) in lat/lon.
> This requires conversion formulas in JavaScript for every projection
> used. I have a formula for the projection we use at work, ETRS-LAEA. If
> anybody wants to contribute more, he/she is very welcome. I can provide
> a document with the UTM/ETRS<->lat/lon formulas for Europe, just needs
> some efforts to bring them into JS.
No, we don't reproject any coordinate. We just open a new popup
window, showing the coordinates of a mouse click. Thus you can copy
the coordinates from there and use in any other appliation of your
will.
Tanti saluti d'Allemania,
Silke
--
Silke Reimer : www.intevation.de/~silke | GISpatcher: www.gispatcher.de
Intevation GmbH: www.intevation.de | Thuban : thuban.intevation.org
Georgstr.4 : 49074 Osnabr?ck | FreeGIS : www.freegis.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://faunalia.it/pipermail/pmapper-users/attachments/20060124/658dd44b/attachment.pgp
