[mapserver-users] Any thoughts on combining 3 regional maps into one?

Stephen Woodbridge woodbri at swoodbridge.com
Wed Oct 2 11:56:05 PDT 2013


Thanks for all the ideas.

Here is a summary of the challenges in doing this:

1. data and tileindex content paths are relative the the shapepath so 
changing the data location relative the the shapepath is problemmatic.

2. data is not consistently presented when working with multiple vendors 
so you can not really merge say streets into one common tileindex or 
postgresql table(s) that gets joined. Well obviously you can program 
anything in sql to make it looks similar but I'm not sure the simplifies 
the problem.

3. with 2200+ lines in the US mapfile and somewhat smaller files for 
each of MX and CA it is a lot to setup in the first place and manage 
through changes and updates.

4. Scribe, cpp, scripts, INCLUDE etc all help to manage the problem but 
often require additional work like rebuilding tileindexes.

One thing that would help would be to add something like:

TILEINDEXP "path/to/my-tileindex"

where TILEINDEX paths are relative to the SHAPEPATH location,
and TILEINDEXP paths are relative to the TILEINDEXP location.

This would allow the MAPFILE paths to change without having to rebuild 
tileindexs. Rebuilding the tileindexes is not hard in and of itself, but 
if you are trying to maintain multiple versions of the TILEINDEXs then 
it can get messy. TILEINDEXP (or whatever you want to call it) means you 
can have a directory with files and a tileindex for those files and it 
is portable to where ever you want to put it in a data tree and the only 
change is the path to the tileindex in the mapfile. And to be clear, the 
path to the TILEINDEXP is relative to the SHAPEPATH and the paths INSIDE 
the TILEINDEXP are relative to its location. Anyway it is an idea that 
could make mapservers data management somewhat easier.

So, now I'll put my head to the ground and plow through something.

-Steve W

On 10/2/2013 1:35 PM, Stephen Woodbridge wrote:
> On 10/2/2013 12:30 PM, Pericles Nacionales wrote:
>> My apologies, I didn't read your message close enough the first time...
>>
>> I guess regardless of how you do it, you'll have to create a new
>> mapfile. Another thought is to define each layer in a separate mapfile
>> and then using "include" to add each of them to a skeleton mapfile. I
>> don't know how much that impacts rendering speed but I know Steve Lime
>> uses that technique and it seems to work well for him.
>
> Thanks Perry,
>
> The whole problem gets messy very fast because of extensive use of
> TILEINDEX and these are all relative to the SHAPEPATH so they will have
> to get rebuild also. So it looks like the options are:
>
> 1. create a trivial mapfile the proxies wms requests to the regional files
>
> 2. create a new mapfile combining everything and probably recreating all
> the tileindex files.
>
> I also thought about using cpp or a script to mangle template mapfiles,
> but changes in the TILEINDEX location makes this non-trivial.
>
> I think I'll try 1. first. It should be ok and is a lot less work, but
> it does not seem to be efficient way to do this.
>
> -Steve
>
>> Hope that helps.
>>
>> -Perry
>>
>> On Oct 2, 2013 11:13 AM, "Pericles Nacionales" <naci0002 at umn.edu
>> <mailto:naci0002 at umn.edu>> wrote:
>>
>>     Steve,
>>
>>     Have you thought about layer groups? Define a group for each
>>     Canadian, US, and Mexican data layers you want to combine...
>>
>>     -Perry
>>
>>     On Oct 2, 2013 10:54 AM, "Stephen Woodbridge"
>>     <woodbri at swoodbridge.com <mailto:woodbri at swoodbridge.com>> wrote:
>>
>>         Hi all,
>>
>>         I have 3 regional mapfiles for US, Canada and Mexico and I want
>>         to create a single North America map. Since the data comes from
>>         separate vendors and they refresh on different cycles, I'm
>>         trying to figure out the best way to structure this in a
>>         mapfile. I also need to maintain each region as a separate
>>         mapfile. (I'm ignoring issues like data alignment over borders.)
>>
>>         The reginal mapfile data is structure like:
>>
>>         .../us/data/<shapefiles>
>>         .../us/us.map
>>         .../mx/data/<shapefiles>
>>         .../mx/mx.map
>>         .../ca/data/<shapefiles>
>>         .../ca/ca.map
>>
>>         The shapepath for each mapfile is set to the local data
>>         directory. What I would like to avoid is having to change all
>>         the paths in the mapfiles to accomodate a change like:
>>
>>         .../na/us/data/
>>         .../na/mx/data/
>>         .../na/ca/data/
>>         .../na/na.map
>>
>>         It would be cool if I can change the shapepath in the middle of
>>         the mapfile so layers beyond the change would use the new
>>         shapepath, but I suspect that will not work.
>>
>>         So it looks like my options are:
>>
>>         1. rewrite all the mapfile data pathes as I combine them into
>>         one new mapfile and maintain two copies, regional and na
>> versions.
>>
>>         2. maybe create a new mapfile that loads each of the regions as
>>         a WMS client and overlays the adjacent regions. This will get
>>         served via mapcache so that might add some options for tile
>>         assembly.
>>
>>         3. other ideas????
>>
>>         Thanks,
>>            -Steve
>>         _________________________________________________
>>         mapserver-users mailing list
>>         mapserver-users at lists.osgeo.__org
>>         <mailto:mapserver-users at lists.osgeo.org>
>>         http://lists.osgeo.org/__mailman/listinfo/mapserver-__users
>>         <http://lists.osgeo.org/mailman/listinfo/mapserver-users>
>>
>
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users



More information about the mapserver-users mailing list