Re: [mapserver-users] Does MapCache supports x-sendfile?

[thomas bonfort]

hi,
short answer: no


On 8 June 2013 02:56, Jackey Cheung  wrote:

> Hi,
>
> Just one short question, Does MapCache supports x-sendfile?
>
> ___
> mapserver-users mailing list
> mapserver-users@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>
>
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

[mapserver-users] Does MapCache supports x-sendfile?

[Jackey Cheung]

Hi,

Just one short question, Does MapCache supports x-sendfile?
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Fwd: RFC99: Remove GD support in 7.0

[Rahkonen Jukka]

Hi,

I made a very short test with Mapnik 2.2.0 demo maps. Mapnik can create png 
images either with AGG or with Cairo and I compared the 256 colour demo maps 
obtained by running the Mapnik c++ version of "rundemo" test program.  Image 
sizes were

AGG 112 kb, went down to 104 kb by optimizing with Irfan view PNGOUT plugin
Cairo 105 kb, went down to 97 kb by optimizing with Irfan view PNGOUT plugin

Perhaps it would be worth having a try with Cairo 8-bit png for small output 
size if we can use it with Mapserver.

-Jukka Rahkonen-



Lähettäjä: mapserver-users-boun...@lists.osgeo.org 
[mapserver-users-boun...@lists.osgeo.org] käyttäjän Richard Greenwood 
[richard.greenw...@gmail.com] puolesta
Lähetetty: 7. kesäkuuta 2013 23:33
Vastaanottaja: mapserver
Aihe: [mapserver-users] Fwd: RFC99: Remove GD support in 7.0

Sorry - posting back to list...

-- Forwarded message --
From: Richard Greenwood 
mailto:richard.greenw...@gmail.com>>
Date: Fri, Jun 7, 2013 at 2:32 PM
Subject: Re: [mapserver-users] RFC99: Remove GD support in 7.0
To: thomas bonfort mailto:thomas.bonf...@gmail.com>>





On Fri, Jun 7, 2013 at 2:00 PM, thomas bonfort 
mailto:thomas.bonf...@gmail.com>> wrote:
(posting back on list)

On 7 June 2013 21:24, Richard Greenwood 
mailto:richard.greenw...@gmail.com>> wrote:
I have continued to use GIF rather than 8bit PNG because the GIF is smaller. 
Often by as much as 15%. Is that expected? Is there anyway to get PNG down to 
GIF size? I certainly understand the rationale for eliminating GD but I am 
discouraged by the prospect of larger image sizes.

I don't think that the gif vs. png format is relevant concerning file size when 
encoding the same pixel data. However, the quantity of information to encode in 
an antialiased image rendering is higher than in a non antialiased one, thus 
the higher file size when using agg/png8 vs. gd/gif. Even if we were to add a 
an agg/gif format, you would still be seeing this size overhead.

Yes, I think I sort of knew that but thanks for clarifying it.

To put this bluntly, if the 15% overhead is important for you, you would have 
to stick with gd aliased rendering and the 6.4 release. I would also like to 
put this in context: a 15% overhead compared to the 2001 (2005?) outputs does 
not seem like a big deal given the evolution of available bandwidth since that 
time.

I work in some pretty rural areas where bandwidth is still limited. And when 
considering bandwidth we need to keep mobile applications in mind alos. 
MapServer has always been synonymous with speed and from the user experience 
perspective speed is determined by the whole pipeline.

We've been supporting this technologically obsolete rendering mode for many 
years now, but imo it's time to move on.

I completely respect that. I was mainly wondering if there was a way to reduce 
the anti-aliasing (and consequently the rendered image file size) when using 
AGG, which I'm sure sounds like a pretty silly question given the "A" in AGG.

Thanks for your reply and for all of the work that you do on the MapServer 
project.

Rich



regards,
thomas


Rich


On Fri, Jun 7, 2013 at 7:27 AM, thomas bonfort 
mailto:thomas.bonf...@gmail.com>> wrote:
Devs and Users,

Please have a look at RFC99 
(http://mapserver.org/development/rfc/ms-rfc-99.html). I am particularly 
interested in use-cases that would not be supported if GD were to be removed.

cheers,
Thomas

___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users




--
Richard Greenwood
richard.greenw...@gmail.com
www.greenwoodmap.com




--
Richard Greenwood
richard.greenw...@gmail.com
www.greenwoodmap.com



--
Richard Greenwood
richard.greenw...@gmail.com
www.greenwoodmap.com
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

[mapserver-users] Fwd: RFC99: Remove GD support in 7.0

[Richard Greenwood]

Sorry - posting back to list...

-- Forwarded message --
From: Richard Greenwood 
Date: Fri, Jun 7, 2013 at 2:32 PM
Subject: Re: [mapserver-users] RFC99: Remove GD support in 7.0
To: thomas bonfort 





On Fri, Jun 7, 2013 at 2:00 PM, thomas bonfort wrote:

> (posting back on list)
>
> On 7 June 2013 21:24, Richard Greenwood wrote:
>
>> I have continued to use GIF rather than 8bit PNG because the GIF is
>> smaller. Often by as much as 15%. Is that expected? Is there anyway to get
>> PNG down to GIF size? I certainly understand the rationale for eliminating
>> GD but I am discouraged by the prospect of larger image sizes.
>>
>
> I don't think that the gif vs. png format is relevant concerning file size
> when encoding the same pixel data. However, the quantity of information to
> encode in an antialiased image rendering is higher than in a non
> antialiased one, thus the higher file size when using agg/png8 vs. gd/gif.
> Even if we were to add a an agg/gif format, you would still be seeing this
> size overhead.
>

Yes, I think I sort of knew that but thanks for clarifying it.


> To put this bluntly, if the 15% overhead is important for you, you would
> have to stick with gd aliased rendering and the 6.4 release. I would also
> like to put this in context: a 15% overhead compared to the 2001 (2005?)
> outputs does not seem like a big deal given the evolution of available
> bandwidth since that time.
>

I work in some pretty rural areas where bandwidth is still limited. And
when considering bandwidth we need to keep mobile applications in mind
alos. MapServer has always been synonymous with speed and from the user
experience perspective speed is determined by the whole pipeline.

We've been supporting this technologically obsolete rendering mode for many
> years now, but imo it's time to move on.
>

I completely respect that. I was mainly wondering if there was a way to
reduce the anti-aliasing (and consequently the rendered image file size)
when using AGG, which I'm sure sounds like a pretty silly question given
the "A" in AGG.

Thanks for your reply and for all of the work that you do on the MapServer
project.

Rich



>
> regards,
> thomas
>
>
>> Rich
>>
>>
>> On Fri, Jun 7, 2013 at 7:27 AM, thomas bonfort 
>> wrote:
>>
>>> Devs and Users,
>>>
>>> Please have a look at RFC99 (
>>> http://mapserver.org/development/rfc/ms-rfc-99.html). I am particularly
>>> interested in use-cases that would not be supported if GD were to be
>>> removed.
>>>
>>> cheers,
>>> Thomas
>>>
>>> ___
>>> mapserver-users mailing list
>>> mapserver-users@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>>>
>>>
>>
>>
>> --
>> Richard Greenwood
>> richard.greenw...@gmail.com
>> www.greenwoodmap.com
>>
>
>


-- 
Richard Greenwood
richard.greenw...@gmail.com
www.greenwoodmap.com



-- 
Richard Greenwood
richard.greenw...@gmail.com
www.greenwoodmap.com
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] MapServer 6.2.1 and ArcSDE 10

[Lime, Steve D (MNIT)]

Ah, I ran into this to as well, see ticket 
https://github.com/mapserver/mapserver/issues/4521. I've attached a diff that 
made things work well for me. Once a fix is put in place for 6.4 (git master) 
we can backport to 6.2.

Steve

From: mapserver-users-boun...@lists.osgeo.org 
[mailto:mapserver-users-boun...@lists.osgeo.org] On Behalf Of Weisbender, Eric
Sent: Friday, June 07, 2013 2:26 PM
To: mapserver-users@lists.osgeo.org
Subject: [mapserver-users] MapServer 6.2.1 and ArcSDE 10

Hello,

We have successfully compiled MapServer 6.2.1 with ArcSDE10 and can see the SDE 
server ok.  When I try to draw a line layer I get the following error.

msDrawMap(): Image handling error. Failed to draw layer named 'sde' 
msSDELayerWhichShapes(): SDE error. getSDEQueryInfo(): Success. (0 
getSDEQueryInfo(): SDE error. SE_queryinfo_set_columns(): Invalid parameter 
value passed to function. (4294967230)

The layer definition looks like this and all of the parameters look good.

LAYER
  NAME "sde"
  TYPE LINE
  STATUS OFF
  CONNECTIONTYPE SDE
  CONNECTION "JLVGISGATEM,5353,sde,cso_editor,c1rcu1t#"
  DATA "RMR.MNT_SPANS,SHAPE,SDE.DEFAULT"
  TEMPLATE "/data/gis/www/html/ms_common/tlines.html"
  CLASS
 STYLE
  COLOR 200 200 0
  WIDTH 10
 END
  END
END

If anyone has an idea of what I am missing or doing wrong any help is greatly 
appreciated.


Thanks,

Eric Weisbender



4521.diff
Description: 4521.diff
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

[mapserver-users] MapServer 6.2.1 and ArcSDE 10

[Weisbender, Eric]

Hello,

We have successfully compiled MapServer 6.2.1 with ArcSDE10 and can see the SDE 
server ok.  When I try to draw a line layer I get the following error.

msDrawMap(): Image handling error. Failed to draw layer named 'sde' 
msSDELayerWhichShapes(): SDE error. getSDEQueryInfo(): Success. (0 
getSDEQueryInfo(): SDE error. SE_queryinfo_set_columns(): Invalid parameter 
value passed to function. (4294967230)

The layer definition looks like this and all of the parameters look good.

LAYER
  NAME "sde"
  TYPE LINE
  STATUS OFF
  CONNECTIONTYPE SDE
  CONNECTION "JLVGISGATEM,5353,sde,cso_editor,c1rcu1t#"
  DATA "RMR.MNT_SPANS,SHAPE,SDE.DEFAULT"
  TEMPLATE "/data/gis/www/html/ms_common/tlines.html"
  CLASS
 STYLE
  COLOR 200 200 0
  WIDTH 10
 END
  END
END

If anyone has an idea of what I am missing or doing wrong any help is greatly 
appreciated.


Thanks,

Eric Weisbender

___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Mapcache and partial reseeding

[thomas bonfort]

Jukka,
yes, the documentation is painfully out of date :( . If you or anyone feels
like updating the mapserver.org docs I'll be happy to assist, however my
schedule these weeks is too full to be able to make this situation evolve
alone.

The seeder options should be available on the command line when you pass it
--help. Those should be complete, however maybe not verbose enough: pull
requests welcome.

regards,
thomas



On 7 June 2013 20:16, Rahkonen Jukka  wrote:

> Hi,
>
> Thanks, sounds great. I wonder where all this is documented? I have been
> reading this page which does not mention "mode=delete" or "force"
> http://www.mapserver.org/trunk/mapcache/seed.html. Doy you know of any
>  other valuable but hidden features?
>
> -Jukka-
> 
> thomas bonfort wrote:
>
>
> On 7 June 2013 17:48, Rahkonen Jukka  jukka.rahko...@mmmtike.fi>> wrote:
> Hi,
>
> How well does Mapcache seeder tool handle the case when the original big
> aerial image coverage is updated little by little so that the hole cycle
> takes 3 to 6 years? Reseeding the whole cache every time when a batch of
> new images is received does not feel like a reasonable solution.
> you can look into the ogr support in the seeder, by giving a
> wkt/shapefile/whatever of the area you want to reseed.
>
> A) Can the seeder tool ake a fast delete for all tiles which intersect the
> update area geometry so that it is guaranteed that outdated tiles are not
> delivered.  Only high zoom levels (Z greater than X) should be purged. Low
> zoom levels may stay as they are because they are not used for
> interpretation.
> depends on what you call fast... the tiles intersecting the area of
> interest need to be iterated and deleted, depending on the area and zoom
> levels that can take some time.
> mode=delete
> ogr source => where you want to delete tiles
> zoom=X,21
> B) Can the seeding tool reseed those areas?
> force
> ogr source
> zoom=X,21
> C) Is the behaviour similar for disk cache and Berkeley DB cache?
> the behavior is identical. the performance is up to you to measure (I have
> no metrics to give you).
>
> regards,
> thomas
>
> -Jukka Rahkonen-
> ___
> mapserver-users mailing list
> mapserver-users@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>
> ___
> mapserver-users mailing list
> mapserver-users@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Slides for MapServer Project Report @foss4gna

[Basques, Bob (CI-StPaul)]

Daniel,

My first blast at it was to concentrate on the LAYER tag as a blob in a 
database. There is definitely room on the DB side to split this blob out at 
some point, but first things first. This would simply be a method for aligning 
the LAYER content with the DATA being used for the layer. It would also allow 
us a method of abstracting out the cartography elements to a certain degree for 
letting the user define things. We use MapServer a little differently within 
GeoMoose in that every layer can have it's own mapfile, which abstracts things 
more than most installations.  We do still have some complicated multi-data 
layers however, and these may break the whole notion of DB stored fragments.

I've read the stuff on the DBINCLUDE as it's come along, and also added in the 
idea of doing a Web call in a similar fashion SCRIPTINCLUDE or URLINCLUDE might 
be better. I've done my share of PERL MapFile assemblers in my time with 
MapServer, so I'm keenly interested in where this all goes.  I've also tried 
some things with SLDs that fell short of providing the MapServer capabilities 
(in my mind) related to automation, etc.

I'll keep an eye out for progress on these items as then happen.

Thanks

Bobb



-Original Message-
From: mapserver-users-boun...@lists.osgeo.org 
[mailto:mapserver-users-boun...@lists.osgeo.org] On Behalf Of Daniel Morissette
Sent: Friday, June 07, 2013 1:49 PM
To: mapserver-users@lists.osgeo.org
Subject: Re: [mapserver-users] Slides for MapServer Project Report @foss4gna

On 13-06-07 2:08 PM, Basques, Bob (CI-StPaul) wrote:
>
> We're in the middle of redesigning some Mapping infrastructure here, and the 
> SVG and ScribeUI stuff looks very interesting.  I wonder, is there some 
> option in the ScribeUI side for putting certain MapFile elements into a 
> database?  We've been wrestling with this idea for some time, and I'm 
> wondering about trying something like this for some of our layers.  The 
> ScribeUI stuff seems like it might be a tool to use for keeping things in a 
> common design format for example.
>


Hi Bob,

Short answer is that no, there is no option to store/manage mapfiles in a 
database in the current ScribeUI plans. However, once ScribeUI is out in the 
wild as an open source project, one could possibly extend it to support 
something along those lines.

BTW, the Google Summer of Code project has been accepted on May 27 and we'll 
try to get our student to release something for the community to look at 
ASAP... quite likely in the next few weeks, so please stay tuned.

And on the topic of storing mapfile elements in a database, Mike Smith has been 
promoting the idea of a DBINCLUDE concept for some time. That hasn't happened 
yet, but might be another avenue that might serve your needs if it was to 
happen or if you'd like to help make it happen. The first step would be to 
define exactly how such a mechanism would work of course.

Daniel
--
Daniel Morissette
http://www.mapgears.com/
Provider of Professional MapServer Support since 2000

___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users


___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Slides for MapServer Project Report @foss4gna

[Daniel Morissette]

On 13-06-07 2:08 PM, Basques, Bob (CI-StPaul) wrote:


We're in the middle of redesigning some Mapping infrastructure here, and the 
SVG and ScribeUI stuff looks very interesting.  I wonder, is there some option 
in the ScribeUI side for putting certain MapFile elements into a database?  
We've been wrestling with this idea for some time, and I'm wondering about 
trying something like this for some of our layers.  The ScribeUI stuff seems 
like it might be a tool to use for keeping things in a common design format for 
example.




Hi Bob,

Short answer is that no, there is no option to store/manage mapfiles in 
a database in the current ScribeUI plans. However, once ScribeUI is out 
in the wild as an open source project, one could possibly extend it to 
support something along those lines.


BTW, the Google Summer of Code project has been accepted on May 27 and 
we'll try to get our student to release something for the community to 
look at ASAP... quite likely in the next few weeks, so please stay tuned.


And on the topic of storing mapfile elements in a database, Mike Smith 
has been promoting the idea of a DBINCLUDE concept for some time. That 
hasn't happened yet, but might be another avenue that might serve your 
needs if it was to happen or if you'd like to help make it happen. The 
first step would be to define exactly how such a mechanism would work of 
course.


Daniel
--
Daniel Morissette
http://www.mapgears.com/
Provider of Professional MapServer Support since 2000

___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Slides for MapServer Project Report @foss4gna

[Basques, Bob (CI-StPaul)]

Daniel,

I didn't get to go to many of the presentations at FOSS4G-NA, so this was good 
for me to get to look through.

We're in the middle of redesigning some Mapping infrastructure here, and the 
SVG and ScribeUI stuff looks very interesting.  I wonder, is there some option 
in the ScribeUI side for putting certain MapFile elements into a database?  
We've been wrestling with this idea for some time, and I'm wondering about 
trying something like this for some of our layers.  The ScribeUI stuff seems 
like it might be a tool to use for keeping things in a common design format for 
example.

Thanks for posting this.

Bobb




-Original Message-
From: mapserver-users-boun...@lists.osgeo.org 
[mailto:mapserver-users-boun...@lists.osgeo.org] On Behalf Of Daniel Morissette
Sent: Friday, June 07, 2013 10:50 AM
To: mapserver-users; 'MapServer Dev List'
Subject: [mapserver-users] Slides for MapServer Project Report @foss4gna

For those interested, a copy of the "MapServer Project Status Report - Meet the 
Developers!" slides that Steve and I gave at FOSS4G-NA in Minneapolis is 
available at:

http://talks.mapgears.com/en/conf/2013-05-23-mapserver-project-status-report

There is a PDF version for easy viewing, and the ODP source is available from 
there as well in case one needs to borrow some slides for their own 
presentations.

--
Daniel Morissette
http://www.mapgears.com/
Provider of Professional MapServer Support since 2000

___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users


___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Mapcache and partial reseeding

[Rahkonen Jukka]

Hi,

Thanks, sounds great. I wonder where all this is documented? I have been 
reading this page which does not mention "mode=delete" or "force" 
http://www.mapserver.org/trunk/mapcache/seed.html. Doy you know of any  other 
valuable but hidden features?

-Jukka-

thomas bonfort wrote:


On 7 June 2013 17:48, Rahkonen Jukka 
mailto:jukka.rahko...@mmmtike.fi>> wrote:
Hi,

How well does Mapcache seeder tool handle the case when the original big aerial 
image coverage is updated little by little so that the hole cycle takes 3 to 6 
years? Reseeding the whole cache every time when a batch of new images is 
received does not feel like a reasonable solution.
you can look into the ogr support in the seeder, by giving a 
wkt/shapefile/whatever of the area you want to reseed.

A) Can the seeder tool ake a fast delete for all tiles which intersect the 
update area geometry so that it is guaranteed that outdated tiles are not 
delivered.  Only high zoom levels (Z greater than X) should be purged. Low zoom 
levels may stay as they are because they are not used for interpretation.
depends on what you call fast... the tiles intersecting the area of interest 
need to be iterated and deleted, depending on the area and zoom levels that can 
take some time.
mode=delete
ogr source => where you want to delete tiles
zoom=X,21
B) Can the seeding tool reseed those areas?
force
ogr source
zoom=X,21
C) Is the behaviour similar for disk cache and Berkeley DB cache?
the behavior is identical. the performance is up to you to measure (I have no 
metrics to give you).

regards,
thomas

-Jukka Rahkonen-
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] cascading wms and layer names encoding

[duartecarreira]

Jukka, thanks for your reply.

Some wms clients do not use the title from layers. They only show the name
(eg qgis). 

As it stands, my wms server creates wms layers names automatically from my
map project, either as a numeric sequence (0,1,2...) or the same string as
the title. (have you guessed which server it is?)
So I was trying to show qgis users something more meaningful than numbers.
And at the same time I was using MapServer to coalesce several layers into
one meaningful single layer, since WMC is so rarelly supported... this way
my users don't have to look at a list of layers and figure out which should
be used together to have a readable map. Since wms services are expensive in
server resources I tend to publish several layers in each one.

So I guess I'll show layers named as numbers and leave it at that...

Duarte



 



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/cascading-wms-and-layer-names-encoding-tp5058504p5058782.html
Sent from the Mapserver - User mailing list archive at Nabble.com.
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Mapcache and partial reseeding

[thomas bonfort]

On 7 June 2013 17:48, Rahkonen Jukka  wrote:

> Hi,
>
> How well does Mapcache seeder tool handle the case when the original big
> aerial image coverage is updated little by little so that the hole cycle
> takes 3 to 6 years? Reseeding the whole cache every time when a batch of
> new images is received does not feel like a reasonable solution.
>
you can look into the ogr support in the seeder, by giving a
wkt/shapefile/whatever of the area you want to reseed.

>
> A) Can the seeder tool ake a fast delete for all tiles which intersect the
> update area geometry so that it is guaranteed that outdated tiles are not
> delivered.  Only high zoom levels (Z greater than X) should be purged. Low
> zoom levels may stay as they are because they are not used for
> interpretation.
>
depends on what you call fast... the tiles intersecting the area of
interest need to be iterated and deleted, depending on the area and zoom
levels that can take some time.
mode=delete
ogr source => where you want to delete tiles
zoom=X,21

> B) Can the seeding tool reseed those areas?
>
force
ogr source
zoom=X,21

> C) Is the behaviour similar for disk cache and Berkeley DB cache?
>
the behavior is identical. the performance is up to you to measure (I have
no metrics to give you).

regards,
thomas

>
> -Jukka Rahkonen-
> ___
> mapserver-users mailing list
> mapserver-users@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

[mapserver-users] Slides for MapServer Project Report @foss4gna

[Daniel Morissette]

For those interested, a copy of the "MapServer Project Status Report - 
Meet the Developers!" slides that Steve and I gave at FOSS4G-NA in 
Minneapolis is available at:


http://talks.mapgears.com/en/conf/2013-05-23-mapserver-project-status-report

There is a PDF version for easy viewing, and the ODP source is available 
from there as well in case one needs to borrow some slides for their own 
presentations.


--
Daniel Morissette
http://www.mapgears.com/
Provider of Professional MapServer Support since 2000

___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

[mapserver-users] Mapcache and partial reseeding

[Rahkonen Jukka]

Hi,

How well does Mapcache seeder tool handle the case when the original big aerial 
image coverage is updated little by little so that the hole cycle takes 3 to 6 
years? Reseeding the whole cache every time when a batch of new images is 
received does not feel like a reasonable solution. 

A) Can the seeder tool ake a fast delete for all tiles which intersect the 
update area geometry so that it is guaranteed that outdated tiles are not 
delivered.  Only high zoom levels (Z greater than X) should be purged. Low zoom 
levels may stay as they are because they are not used for interpretation.
B) Can the seeding tool reseed those areas?
C) Is the behaviour similar for disk cache and Berkeley DB cache?

-Jukka Rahkonen-
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Best way to import 4.5TB of imagery?

[Stephen Woodbridge]

On 6/7/2013 10:31 AM, James_in_Utah wrote:

Hi,
We just got 3 hard drive, loaded with 4.5TB of NAIP imagery for all of
CONUS.  I think there's a total of about 400,000 jpgs.  The data is in
directories, by states.  Under each state, there are subfolders, probably
reference by longitude.  Other than going through folder by folder, adding
each image to a shape file using gdaltindex, what's the best strategy for
loading a couple of hundred thousand files up to our server and making the
imagery available via our mapserver?  Should I maintain the current
directory structure when I copy the imagery to the server, or just dump all
of it into a single directory?  Do I want to stay with 1 shape file, or
break it up by state?  We eventually want a contiguous layer for all of
CONUS to be served up to our users.


James,

Since imagery data is served via gdal, you might want to also ask this 
question on the gdal list.


There are issues with jpg related to the fact that if you only want a 
small part of the image you still have to uncompress the whole image. So 
part of the answer might be that you need to pre-process all the imagery 
into something like a jpg compress tiled geotif or something else.


You also need to consider what projection your imagery is in and what 
projection you want to display it in. Because if you need to preprocess 
the data, that would also be a good time to reproject it.


Anyway the gdal list can probably ask additional questions to help sort 
all that out.


-Steve W

___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

[mapserver-users] Best way to import 4.5TB of imagery?

[James_in_Utah]

Hi,
We just got 3 hard drive, loaded with 4.5TB of NAIP imagery for all of
CONUS.  I think there's a total of about 400,000 jpgs.  The data is in
directories, by states.  Under each state, there are subfolders, probably
reference by longitude.  Other than going through folder by folder, adding
each image to a shape file using gdaltindex, what's the best strategy for
loading a couple of hundred thousand files up to our server and making the
imagery available via our mapserver?  Should I maintain the current
directory structure when I copy the imagery to the server, or just dump all
of it into a single directory?  Do I want to stay with 1 shape file, or
break it up by state?  We eventually want a contiguous layer for all of
CONUS to be served up to our users.
Thanks,
James




--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Best-way-to-import-4-5TB-of-imagery-tp5058745.html
Sent from the Mapserver - User mailing list archive at Nabble.com.
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] RFC99: Remove GD support in 7.0

[Stephen Woodbridge]

On 6/7/2013 9:27 AM, thomas bonfort wrote:

Devs and Users,

Please have a look at RFC99
(http://mapserver.org/development/rfc/ms-rfc-99.html). I am particularly
interested in use-cases that would not be supported if GD were to be
removed.


Thomas,

+1 I am all for moving forward with this proposal.

The only use case that I can think of for GD renders was to generate 
unaliased vector rendering for transparent images because the image size 
was significantly smaller. I'm not aware if this is still needed or who 
was using it for that matter.


Regardless, those people always have the option of remaining on an old 
version of mapserver and potentially contracting for fixes if they 
decide they need them.


-Steve W
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

[mapserver-users] RFC99: Remove GD support in 7.0

[thomas bonfort]

Devs and Users,

Please have a look at RFC99 (
http://mapserver.org/development/rfc/ms-rfc-99.html). I am particularly
interested in use-cases that would not be supported if GD were to be
removed.

cheers,
Thomas
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users