[GRASSLIST:885] Contracted Grass support?

GRASS GRASS user
1

Hello

I'm looking to contract a grass developer or 'expert' to analyses some
ESRI 'shape' files. (Streets, Highways and Rivers etc), in brief:

1. Develop a scripted import mechanism which would import ALL the
map information, attributes, labels and categories etc.

2. Display the vector layers including labels.

3. Produce rasta images which reference specified 'art rules' ie:
road_thickness,
road_border_color, including labels.

I've been told that I have to use "ArcInfo" software to produce 'eye candy'
maps, however I'm determined to use Grass, even it requires purchasing
custom
development.

Please quote experience, hourly rate and time estimate.

Regards
Bruce Bushby

2

Hello Bruce,

On Fri, Aug 01, 2003 at 11:25:04PM +0200, Bruce Bushby wrote:

I'm looking to contract a grass developer or 'expert' to analyses some
ESRI 'shape' files. (Streets, Highways and Rivers etc), in brief:

Note that there are several companies
offering commerical support around GRASS.

The Webmaster of the GRASS team, Markus Neteler keeps a list at:
http://grass.itc.it/commercial.html#support
All those companies have experience with GRASS.

I'm representing one of the companies and
will email you my more detailed company information seperately.

1. Develop a scripted import mechanism which would import ALL the
map information, attributes, labels and categories etc.

2. Display the vector layers including labels.

3. Produce rasta images which reference specified 'art rules' ie:
road_thickness,
road_border_color, including labels.

I've been told that I have to use "ArcInfo" software to produce 'eye candy'
maps, however I'm determined to use Grass, even it requires purchasing
custom
development.

If your goal is good looking maps,
many cartographers prefer to do the map development and analysis
with GRASS and produce vector output formats which are then
processed with more general Free Software graphic applications.

Thus depending on your goals using a software chain like GRASS -> Sketch
or GRASS -> Thuban -> Sketch can produce nicer maps for printing.
If you need nice raster maps for onscreen display, UNM Mapserver
might also be a possible component of this chain.

Depending on a better knowledge of your goals
this sort of solution is what we would offer.

Please quote experience, hourly rate and time estimate.

Especially the level of 'art rules' would be a major item
for the time estimate.

Regards,
  Bernhard

--
Professional Service for Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)

3

> I've been told that I have to use "ArcInfo" software to produce 'eye
> candy' maps, however I'm determined to use Grass, even it requires
> purchasing custom
> development.

If your goal is good looking maps,
many cartographers prefer to do the map development and analysis
with GRASS and produce vector output formats which are then
processed with more general Free Software graphic applications.

For what it's worth, I think ps.map does a pretty good job of making
good looking, precisely laid out hard copies, especially if you want to
create a template to create many maps of the same region.

Granted it takes some learning, isn't the prettiest of interfaces, and I
had to edit some of the source code to get it to look exactly the way I
wanted it to, but with a little work I am very happy with the results.

While other software such as GMT may still do a better job, it is
possible to make ps.map produce nice output.

Hamish

4

On Sat, 2 Aug 2003, Bernhard Reiter wrote:

...

> 1. Develop a scripted import mechanism which would import ALL the
> map information, attributes, labels and categories etc.
>
> 2. Display the vector layers including labels.
>
> 3. Produce rasta images which reference specified 'art rules' ie:
> road_thickness,
> road_border_color, including labels.
>
> I've been told that I have to use "ArcInfo" software to produce 'eye candy'
> maps, however I'm determined to use Grass, even it requires purchasing
> custom
> development.

If your goal is good looking maps,
many cartographers prefer to do the map development and analysis
with GRASS and produce vector output formats which are then
processed with more general Free Software graphic applications.

Thus depending on your goals using a software chain like GRASS -> Sketch
or GRASS -> Thuban -> Sketch can produce nicer maps for printing.
If you need nice raster maps for onscreen display, UNM Mapserver
might also be a possible component of this chain.

Although this doesn't address the problem of importing the shapefiles
well. I feel the kind of solution the original poster was looking for
would be something based around GRASS 5.7.x (previously 5.1), involving
some kind of wrapper script for v.in.ogr specifically for shapefiles,
possibly improvements to v.in.ogr and to ps.map and maybe some kind of
v.to.rast for 5.7.x that uses special vector attributes (possibly created
by the modified v.in.ogr / script) to determine how it creates the raster
layer.

5

On Sun, Aug 03, 2003 at 10:22:41AM +0100, Paul Kelly wrote:

On Sat, 2 Aug 2003, Bernhard Reiter wrote:

> If your goal is good looking maps,
> many cartographers prefer to do the map development and analysis
> with GRASS and produce vector output formats which are then
> processed with more general Free Software graphic applications.
>
> Thus depending on your goals using a software chain like GRASS -> Sketch
> or GRASS -> Thuban -> Sketch can produce nicer maps for printing.
> If you need nice raster maps for onscreen display, UNM Mapserver
> might also be a possible component of this chain.

Although this doesn't address the problem of importing the shapefiles
well.

True.

I feel the kind of solution the original poster was looking for
would be something based around GRASS 5.7.x (previously 5.1), involving
some kind of wrapper script for v.in.ogr specifically for shapefiles,
possibly improvements to v.in.ogr and to ps.map and maybe some kind of
v.to.rast for 5.7.x that uses special vector attributes (possibly created
by the modified v.in.ogr / script) to determine how it creates the raster
layer.

We can't tell what the priorities of the original poster are
lacking more information. I'd welcome your interpretation very much.
On the other hand, if he his very much goal driven
a combination of Free Software GIS products might help him
reach hist goals faster, subsequently also indirectly helping GRASS.

Taking along term perspective I'm maintaining a vision
where Free Software components work together nicely
and have their strength on their main task
bringing us the building blocks to do geographic information processes
in many powerful combination. I also believe that the synergies
the FreeGIS proejct has created already let to many connections
between the existing Free Software projects.

6

On Sat, 2 Aug 2003, Bernhard Reiter wrote:

If your goal is good looking maps,
many cartographers prefer to do the map development and analysis
with GRASS and produce vector output formats which are then
processed with more general Free Software graphic applications.

I have found GMT (Generic Mapping Tools) creates very attractive maps for
screen or publication. As this is command line driven, GRASS scripts can
easily export the required data to plot with GMT commands in teh same
script, integrating pretty seamlessly.

7

On Mon, 4 Aug 2003, Brent Wood wrote:

On Sat, 2 Aug 2003, Bernhard Reiter wrote:

>
> If your goal is good looking maps,
> many cartographers prefer to do the map development and analysis
> with GRASS and produce vector output formats which are then
> processed with more general Free Software graphic applications.
>

I have found GMT (Generic Mapping Tools) creates very attractive maps for
screen or publication. As this is command line driven, GRASS scripts can
easily export the required data to plot with GMT commands in teh same
script, integrating pretty seamlessly.

See here for some discussion about including vector drawing attributes in
the 5.1 vector format:
http://grass.baylor.edu/grass51/grass51_vector_discussion.txt
Search for '----' and read below that.
It is kind of a nice idea but would need to be thought through very
clearly so it wasn't implemented messily.

At the minute I agree also now it seems GMT may be the way to go, or
possibly something like Thuban depending on how interactive it needs to
be. But certainly it would be possible to do a nice comprehensive
solution within GRASS if staying within GRASS was a prime aim, and the
database support makes the 5.1 vector architecture very extensible and
useful. Certainly though I would look at ps.map instead of p.map; p.map
doesn't even exist in 5.7.x(5.1) GRASS and ps.map can do vector labels.

Paul Kelly