Frederik Ramm wrote:
> Also see comment on line 611ff where it will emit extra polygons for
tagged inner rings - i.e. one multipolygon relation might yield more
than one polygon feature on output.
>
> All this is probably only halfway there. I'd be very interested in ideas
how to fix broken m
Hi,
On 02/18/11 10:16, Jukka Rahkonen wrote:
Once you have found a perfect solution, how about placing it somewhere in
front of the OSM database instead? Wouldn't it be better to prevent OSM
users from inserting invalid multipolygons than try to fix them temporary
every time they are used?
No,
>I think I have these resources in order from most significant to least
>significant for the average app store app. So when he says
>"client-side", I'm starting to wonder because client-server apps are
>generally less responsive and require more mobile bandwidth, consuming
>2 precious resources.
I
Frederik Ramm wrote:
> Hi,
>
> On 02/18/11 10:16, Jukka Rahkonen wrote:
>> Once you have found a perfect solution, how about placing it somewhere
>> in
>> front of the OSM database instead? Wouldn't it be better to prevent OSM
>> users from inserting invalid multipolygons than try to fix them
>> te
Hi,
On Fri, Feb 18, 2011 at 08:22:54AM +0100, Frederik Ramm wrote:
> Hi,
>
> On 02/18/11 04:35, Daniel Sabo wrote:
>>> Makes sense. Do you do anything about touching inner rings?
>>
>> No, and I haven't thought of a good way to handle it. If you have an
>> algorithm that works well I'd be
I experience a strange behaviour in osm2pgsql: when I import data all
closed highways go into planet_osm_polygon (and none of them in line
or roads) regardless if they have area=yes set or not. Does anybody
know if there was a bug (I am using October 2010 version of osm2pgsql)
in osm2pgsql? Because
I initially followed this guide when setting up OSM + Renderd.
http://weait.com/content/build-your-own-openstreetmap-server
I've matched the suggestions made in the guide:
shared_buffers = 128MB
checkpoint_segments = 20
maintenance_work_mem = 256MB
autovacuum = off
I keep hearing debate about a
Hi,
On 02/18/11 14:56, Jukka Rahkonen wrote:
Once you have found a perfect solution, how about placing it somewhere
in front of the OSM database instead?
[...]
No, for several reasons. One of them is purely technical
I was thinking about the same. What are the other reasons? One that come
So, I just added the historical map I created.
Click on "Make Map" and login:
http://geocommons.com/overlays/93944
Or, if you're logged in, this should allow you to go directly to the map:
http://geocommons.com/maps/52565/edit?add_id=93944
When you see the map, click in the upper-left and choose
Though GeoCommons is quite beautifully done, it is designed with significant
limitations.
*First and foremost, it is not designed like a wiki, where people can
collaborate and add to the map. There is nothing for editing the map
internally, like openstreetmap, and nothing for discussing it. Geocomm
I think the actual configuration depends on your system and the free
resources you have. You should give us a little bit more information
about expected connections, available ram, update interval of your
database and so on.
General information about postgres resource configuration can be found
he
... looks like they use some of the same features, and some of the same
people are involved as in openstreetmap:
http://geocommons.com/help/Open_Source
nitin
On Fri, Feb 18, 2011 at 12:44 PM, Nitin Gadia wrote:
> Though GeoCommons is quite beautifully done, it is designed with
> significant lim
Martin,
Your remote mounting an ftp server directory idea is really good. I have
not got ssh access to my server at the moment, but I could achieve the same
on Ubuntu using:
sudo apt-get install curlftpfs
curlftpfs ftp://:@
It seems to work really well - Thanks!
Graham.
On 17 February 2011
13 matches
Mail list logo