Hello,
Please tell me if I'm replicating any initiative or doing something the
wrong or a not-so-good way.
I've started this week from an EBS backed (or boot) Ubuntu 8.04 image
ami-f6ad409f.
I agree to give the .pem file for ssh connection to an instance to anyone
willing to collaborate.
My
2010/1/8 Jonathan-David SCHRODER jonathan.schro...@gmail.com
Hello,
Please tell me if I'm replicating any initiative or doing something the
wrong or a not-so-good way.
I've started this week from an EBS backed (or boot) Ubuntu 8.04 image
ami-f6ad409f.
I agree to give the .pem file for ssh
I would like to have an account.
We could try out some ideas for replacing the database with a lot of
small files.
mike
On Fri, Jan 8, 2010 at 1:42 PM, Emilie Laffray emilie.laff...@gmail.com wrote:
2010/1/8 Jonathan-David SCHRODER jonathan.schro...@gmail.com
Hello,
Please tell me if I'm
Hello,
I'm part of MapOSMatic developers. Currently, we are using osm2pgsql
to translate OSM data into Posgresql, as usual. We are using the
default configuration for osm2pgsql. In particular, the tag name is
translated into a pgsql column name.
We would like to support multiple names for a
We would like to support multiple names for a given street: name:fr,
name:ar, etc. As far as I have understood, we could configure
osm2pgsql to create columns name:fr, name:ar, etc. and change our
SQL requests to use those columns. That does not seems very scalable.
The ideal
I have been working on c++ code with rtrees and other nice things.
depending on what you want to do with it, I think it is fair to make
updates very slow if the rendering is very fast...
mike
On Fri, Jan 8, 2010 at 2:39 PM, Stefan de Konink ste...@konink.de wrote:
Op 08-01-10 13:49,
On Fri, Jan 8, 2010 at 12:57 PM, David MENTRE dmen...@linux-france.org wrote:
The ideal configuration would be to have all names (name:fr, name:ar,
...) into a single name column and use it. Or have a kind of couple
(name, country_code) that would store all different names for a
street. But I
Now both to list.
Op 08-01-10 14:53, jamesmikedup...@googlemail.com schreef:
On Fri, Jan 8, 2010 at 2:50 PM, Stefan de Koninkste...@konink.de wrote:
Op 08-01-10 14:46, jamesmikedup...@googlemail.com schreef:
I have been working on c++ code with rtrees and other nice things.
depending on
Hello Brian,
2010/1/8 Brian Quinion openstreet...@brian.quinion.co.uk:
That is how the gazetteer output from osm2pgsql handles it already.
Thanks a lot!
Regards,
d.
___
dev mailing list
dev@openstreetmap.org
Op 08-01-10 15:09, jamesmikedup...@googlemail.com schreef:
I dont know all the details of mapnik, but from what I have seen,
using the postgres database is not needed in all cases.
I am thinking about
It is not required to use the database, but the overhead is in the
rendering. I do agree
When I change the position of a node, will the way be in the changeset, too?
When I change members of relations (without adding / removing members),
will the relation be in the changeset, too?
I have currently no data to test these cases, so does anybody know how
the results of these operations
On Fri, Jan 8, 2010 at 3:23 PM, Stefan de Konink ste...@konink.de wrote:
Op 08-01-10 15:09, jamesmikedup...@googlemail.com schreef:
I dont know all the details of mapnik, but from what I have seen,
using the postgres database is not needed in all cases.
I am thinking about
It is not required
Op 08-01-10 15:39, jamesmikedup...@googlemail.com schreef:
Tiny would have to be an osmtile in binary format, agreed?
Yes, well if you sort the data properly then mapnik would just render
the data in a sax callback, right?
Jup, but you will never get better results of that storing in parts
Ok, well I am going to first work on making the mapnik be able to
render an osm file standalone without postgis,
will report back when that works.
mike
On Fri, Jan 8, 2010 at 3:50 PM, Stefan de Konink ste...@konink.de wrote:
Op 08-01-10 15:39, jamesmikedup...@googlemail.com schreef:
Tiny would
jamesmikedup...@googlemail.com wrote:
Ok, well I am going to first work on making the mapnik be able to
render an osm file standalone without postgis,
will report back when that works.
*cough* http://trac.mapnik.org/browser/trunk/plugins/input/osm
Will not work with the postgis-based
Andreas Kalsch andreaskal...@gmx.de writes:
When I change the position of a node, will the way be in the changeset, too?
When I change members of relations (without adding / removing members),
will the relation be in the changeset, too?
When you change a node only the node is uploaded to the
So this renderes directly from an osm file?
On Fri, Jan 8, 2010 at 4:02 PM, Lennard l...@xs4all.nl wrote:
jamesmikedup...@googlemail.com wrote:
Ok, well I am going to first work on making the mapnik be able to
render an osm file standalone without postgis,
will report back when that works.
http://wiki.openstreetmap.org/wiki/Mapnik#Data_Sources
This webpage only talkes about posgis, is there any documentation that
covers the osm direct rendering?
mike
On Fri, Jan 8, 2010 at 4:08 PM, jamesmikedup...@googlemail.com
jamesmikedup...@googlemail.com wrote:
So this renderes directly from
Hi,
When I change the position of a node, will the way be in the changeset, too?
No.
When I change members of relations (without adding / removing members),
will the relation be in the changeset, too?
No.
Bye
Frederik
___
dev mailing list
On Jan 8, 2010, at 7:19 AM, jamesmikedup...@googlemail.com wrote:
http://wiki.openstreetmap.org/wiki/Mapnik#Data_Sources
This webpage only talkes about posgis, is there any documentation that
covers the osm direct rendering?
http://trac.mapnik.org/wiki/OsmPlugin
Ok, this looks great.
So, now, that would be my suggestion to use on this amazon webservice.
A lot of small osm files, the size of the smallest tile.
Now, on thing did occur to me while walking the dog, we could render
multiple zoom levels at once.
Every time you render the smallest unit (tile)
On the toolserver we imported with this style [1] and so have the name,
name:de, name:fr, etc. columns. Then we used the script [2] to created
one view for each language and for each table:
SELECT planet_osm_point.osm_id, planet_osm_point.access,
planet_osm_point.addr:flats,
I noticed that some exceptions get localized messages like this one:
IllegalArgumentException(tr(Parameter ''{0}'' must not be null., tags))
Does this really help anyone? Those messages are intended to be for
developers and users probably won't know what to do even with the best
translation.
My suggestion is to throw just english language exceptions. All exceptions
should have some code and this code can be key in some wiki page with
tutorials how to remove occurence of exceptions. Ideal is link in exception
window. Googling for number could be sometimes problem.
For developer
Hi,
I would vote for removing those lokalizations.
Me too. There are lots of them, though, and I even have to admin that lots of
them have been introduced by me. In hindsight this looks increasingly silly. We
should follow more appropriate rules than those currently mentioned in
Dirk Stöcker openstreet...@dstoecker.de writes:
Message intended to be visible to user must be translated. Messages
meant as security checks or debugging texts which never should be visible
to a user may remain untranslated.
When in doubt they should be translated, but also descriptive for
26 matches
Mail list logo
