Tim Teulings wrote:
OK. It would be nice if you can send me a list of "things to avoid" or
a diff of your changes, so I can change the code. Depending of the
size of the changes I see possible alternatives:
* Use ifdefs (only if the amount of changes is small)
* Move such includes to a project header that does all the includes
(again possibly with ifdefs)
* Move to supported includes.
A suggestion would be helpful.
Currently, the code is still not actually working under msvc(see below).
I may send you the diff and suggestion later after it works.
I would like to avoid the use of boost if possible. I tried to switch
to boost for another project a longer time ago and even didn't get it
to install under Windows because of some
strange (phyton based?) build tool at that time. I think installation
is now easier but still would like to keep the installation barrier
and external dependencies as small as possible. Curremntly the only
forced dependency is libxml and this could possibly be droped for Qt
users (AFAIK Qt has also XMl parsing support) if changes are small. So
boost for me is only an option if there are substancial benefits and
very easy installation and high portability.
That must be a long time ago. Using the boost build system bjam, two
line of command will do all the job.
Of course, you don't have to build all the lib. Plus, most of the boost
libs are header only.
Thanks. Download worked and I got some problems because of corner
cases because of the small size of the file (no relevant
relations...). I did some changes to the code so it should not be more
robust. TravelJinni and OSMScout now corretcly show the data.
After updating, the import didn't crash but gave following output:
+ Loading type config...
+ 1 Preprocess...
Nodes: 2311
Ways/Areas/Sum: 72 230 302
Relations: 16
+ 2 Generating 'rawnode.idx'...
- Generating 'rawnode.idx'...
Cannot read uint32_t beyond file end!
!! Error while reading number of data entries in file
!! Error while executing step Generating 'rawnode.idx'!
Import failed!
I'm using the stdint.h from
http://msinttypes.googlecode.com/svn/trunk/stdint.h, suggested by wiki
page. Dose it matter?
I also note the HAVE_MMAP, should I define it?
Note however the file I downlaoded shows Prag not Shanghai ;-)
Alas, I mistook the file name, but that should be the file which crashed
the import.
I did a quick scan: It looks very low level and the API is a little
bit unintuitive to me (and cairo and Qt personally cover all my target
platforms), but since the general requirements for a backend are:
* vectorial polygon line drawing (any width, any color, alpha channel)
* Influence line ending style
* vectorial polygon area fill (any color, alpha channel)
* Font handling (font loading, font styles, size of text bounding area)
* Drawing text, especially along any path (any color, alpha channel)
this library could be used as possible backend, too. I assume if you
are experienced in agg, it might take you < 1 day for first results,
possibly 2-3 days to finish work. The drawing backend interface
currently is suboptimal because it contains some logic that should be
placed into the base class backend driver, adding further backend
should help refining the interface to fit better. After refining,
implementation is done likely even faster :-)
Well, agg may be kinda low-level for part of you purpose. Mainly these
text drawing stuff, but you can use some font lib like freetype to gain
a much better text drawing support. Agg is small, fast and portable.
I've tried cairo under windows, but the performance was not so
satisfactory. I also prefer the agg's c++ way. The only problem may be
the development has been hung for a long time. I'd mention mapnik here
again. It has both agg and cairo render support, and they all work well
under same framework.
--Regard, zsj
_______________________________________________
Routing mailing list
Routing@openstreetmap.org
http://lists.openstreetmap.org/listinfo/routing
