On Sun, Jun 5, 2011 at 7:38 PM, Scott Crosby wrote:
> On Sun, Jun 5, 2011 at 8:41 AM, Anthony wrote:
>> On Sun, Jun 5, 2011 at 8:39 AM, Frederik Ramm wrote:
>>> Linestrings with internal geometries are very unlikely to happen, for a
>>> number of reasons, one of them being topology.
>>
>> That's
On Sun, Jun 5, 2011 at 8:41 AM, Anthony wrote:
> On Sun, Jun 5, 2011 at 8:39 AM, Frederik Ramm wrote:
>> Linestrings with internal geometries are very unlikely to happen, for a
>> number of reasons, one of them being topology.
>
> That's too bad. More than 90% of node ids are completely useless
On 6 June 2011 04:32, Jaak Laineste wrote:
> relevant for officials and no much more. So also in our cartographic
> tradition we still use primary dimension (colors) for surface, and
> secondary (width, style) for other road parameters.
Australia has a large amount of dirt roads, I'm pretty sure
2011/6/5 John Smith :
> On 6 June 2011 03:22, Richard Weait wrote:
>> Why must the "problem" of rendering surface tags be solved on a
>> specific rendered layer or service?
>
> The answer is obvious, it's easier to push a small change onto the
> main mapnik layer than running their own system.
I'
On 6 June 2011 03:22, Richard Weait wrote:
> Why must the "problem" of rendering surface tags be solved on a
> specific rendered layer or service?
The answer is obvious, it's easier to push a small change onto the
main mapnik layer than running their own system.
I'm not sure how much the custom
On Sun, Jun 5, 2011 at 12:02 PM, Jean-Guilhem Cailton wrote:
> Hi,
>
> Sorry if this would be better suited for talk (or another) mailing list.
> Just following a thread that was started here, for good reason.
>
> Sincerely, I am surprised to see that there could be "tension" around
> that proposa
Hi,
Sorry if this would be better suited for talk (or another) mailing list.
Just following a thread that was started here, for good reason.
Sincerely, I am surprised to see that there could be "tension" around
that proposal.
It is not about adding objects to the map, but actually about removing
>>> Imagine there's a way with anonymous points and you make a branch off of
>>> that. You'd have to convert that node to a "proper" node and split the
>>> linestring. We'd end up with a crippled system like "routable shapefiles"
>>> where you need an individual linestring for each bit of way betwe
Hi,
Anthony wrote:
Imagine there's a way with anonymous points and you make a branch off of
that. You'd have to convert that node to a "proper" node and split the
linestring. We'd end up with a crippled system like "routable shapefiles"
where you need an individual linestring for each bit of way
On Sun, Jun 5, 2011 at 10:08 AM, Frederik Ramm wrote:
> Hi,
>
> Anthony wrote:
>>
>> That's too bad. More than 90% of node ids are completely useless as
>> they refer to only one way. This is a significant drag on the
>> database,
>
> Yeah well. There are other ways we could reduce "drag" on the
Hi,
Anthony wrote:
That's too bad. More than 90% of node ids are completely useless as
they refer to only one way. This is a significant drag on the
database,
Yeah well. There are other ways we could reduce "drag" on the database
but introduce problems. This is one of them ;)
Imagine the
On Sun, Jun 5, 2011 at 8:39 AM, Frederik Ramm wrote:
> Linestrings with internal geometries are very unlikely to happen, for a
> number of reasons, one of them being topology.
That's too bad. More than 90% of node ids are completely useless as
they refer to only one way. This is a significant d
On 05.06.2011, at 14:01, Stefan Keller wrote:
>> Thanks for the comparison.
>> I'm the author of Imposm, so I have some clarifications :)
>>
>> It is written in Python and _uses_ C/C++ libraries.
>
> I've added that.
Great.
> So this seems to be similar with our osm2gis.
> osm2gis supports als
Hi,
Stefan Keller wrote:
True. I'm promoting that change to polygons as a "first class data
type" since years... In fact, if ways would be encoded as a first
class data type too (e.g. as linestring encoded by way_id and a set of
anon. coordinates) then we would'nt run out of the int4 byte range
Hi Oliver
2011/6/5 Oliver Tonnhofer :
> Hi Stefan,
>
> On 05.06.2011, at 01:09, Stefan Keller wrote:
>> I'm the project leader of osm2gis.
>> I've tried to do a characterization of the projects mentioned before:
>> http://dev.ifs.hsr.ch/redmine/projects/osminabox/wiki/Wiki
>
>
> Thanks for the com
Hi,
2011/5/24 Jukka Rahkonen :
...
> Spatialite_osm_map with the finland.osm dataset from Geofabrik
> is faster than osm2pgsql in slim mode with my laptop. I have not studied
> spatialite_osm_map thoroughly and I do not know how well it has solved the
> mystery of OSM polygons but that is somethin
Hi Stefan,
On 05.06.2011, at 01:09, Stefan Keller wrote:
> I'm the project leader of osm2gis.
> I've tried to do a characterization of the projects mentioned before:
> http://dev.ifs.hsr.ch/redmine/projects/osminabox/wiki/Wiki
Thanks for the comparison.
I'm the author of Imposm, so I have some c
17 matches
Mail list logo
