Opened 17 years ago

Closed 13 years ago

#2115 closed defect (fixed)

AGG palette formatoption requires absolute path

Reported by: jmckenna Owned by: sdlime
Priority: normal Milestone: 6.0 release
Component: MapServer C Library Version: 5.0
Severity: normal Keywords:
Cc: assefa, zjames, warmerdam, tbonfort, aboudreault

Description (last modified by warmerdam)

Relative paths to the AGG palette file do not work:

OUTPUTFORMAT
    NAME "agg/png24"
    MIMETYPE "image/png; mode=24bit"
    DRIVER "AGG/PNG"
    EXTENSION "png"
    IMAGEMODE "RGB"
    FORMATOPTION "PALETTE_FORCE=TRUE"
    FORMATOPTION "PALETTE=palette.txt"  
END 

causes this error: msImageCreateWithPaletteGD(): Unable to access file. Error opening palette file palette.txt

It should be relative to the location of the mapfile.

Change History (18)

comment:1 by sdlime, 17 years ago

Component: AGGMapServer C Library

I agree and would have set it up that way if it were straightforward. Problem is that the image handling is basically mapfile independent and I don't have access to the stored path from an image format object. Not sure how best to handle...

Also changing component since this isn't specific to AGG.

Steve

comment:2 by sdlime, 17 years ago

Status: newassigned

comment:3 by jmckenna, 17 years ago

Cc: yassefa@… added

comment:4 by zjames, 17 years ago

Cc: zjames added

comment:5 by hobu, 17 years ago

Milestone: 5.0 release5.2 release

Pushing this forward to 5.2, maybe we can figure out a clean way to deal with it then.

comment:6 by sdlime, 17 years ago

We'll need to stuff the map path in the image object some place OR pass mapObj's around in places we haven't in the past.

Steve

comment:7 by sdlime, 16 years ago

Cc: warmerdam added

Anybody have ideas on how to best address? I see at least three options:

1 - add a new structure member, a pointer back to the parent mapObj to outputFormatObj's 2 - add a new structure member (mappath) to outputFormatObj's to hold the value of mappath from the initializing mapObj 3 - add code to mapfile.c so that mappath is added as a format option in cases where PALETTE= is found.

1 is something we do elsewhere (e.g. layers) and would keep the outputFormatObj in sync with the mapObj and is probably the easiest to implement.

Thoughts?

Steve

comment:8 by warmerdam, 16 years ago

Description: modified (diff)

Steve,

What about changing msSaveImage() to pass the mapObj * down into msSaveImageGD() and msSaveImageGDCtx()? msSaveImageGDAL() already requires the mapObj.

I'm not keen on "back pointers" to the map in objects like the outputFormatObj because they are tricky to keep valid when things are moved around.

comment:9 by sdlime, 16 years ago

Can certainly try that, thanks for the input.

Steve

comment:10 by sdlime, 16 years ago

Milestone: 5.2 release5.4 release

Argh, I don't think that will work. The function that mapscript uses to return an image buffer (e.g. msSaveImageBuffer) also needs the mapObj then. Problem is that it would require a change to the mapscript api to make that happen and I don't want to do that. Not for something this insignificant and not for a 5.x release.

We need to keep those function signatures consistent. I knew this would be a pain so I'm deferring until 5.4.

Steve

comment:11 by warmerdam, 16 years ago

Steve,

I see that the mapscript imageObj.save() method takes an optional map argument. Why couldn't the getBytes() and getSize() methods on the imageObj also take this as an optional argument? I don't see how that would be break backward compatability. The current msSaveImageBuffer() really doesn't work properly (as far as I can tell) for situations where a map is required - such as saving to geotiff with georeferencing which requires the mapObj.

Looking at the code I'm somewhat horrified at the duplication between the msSaveImage() functions and the msSaveImageBuffer() functions and the fact that one takes a mapObj and one doesn't - for no apparent reason.

With some care for backward compatability (ie. map mapObj an optional argument) I don't see why this couldn't be done at 5.2 without adverse effects on existing scripts.

comment:12 by sdlime, 16 years ago

Milestone: 5.4 release5.2 release

I'm not sure devs even know about msSaveImageBuffer(). It always seems to be out of sync with msSaveImage. Would be nice to have one function with file and buffer-based wrappers. I'll look into optional argument solution. I added everything necessary the other night but stopped when I saw the missing argument to msSaveImageBuffer()...

Will shoot for 5.2.

Steve

comment:13 by sdlime, 16 years ago

Moving to 5.4, no time...

Steve

comment:14 by sdlime, 16 years ago

Milestone: 5.2 release5.4 release

comment:15 by tbonfort, 15 years ago

also reported in #2577

comment:16 by sdlime, 13 years ago

Cc: tbonfort added

Thomas, is this an issue with the new rendering code?

Steve

comment:17 by dmorissette, 13 years ago

Cc: assefa aboudreault added; dgadoury@… yassefa@… removed
Milestone: 5.6 release6.0 release

Moving to 6.0.

comment:18 by tbonfort, 13 years ago

Resolution: fixed
Status: assignedclosed

fixed in r11521 for msSaveImage()

The change is not active for msSaveImageBuffer as that would lead to changes in the mapscript api that I am not willing to take on.

closing this one, mapscript users of msSaveImageBuffer that need the functionality can open a new request/bug if needed

Note: See TracTickets for help on using tickets.