Flightgear-commitlogs wrote:
The branch, gdalchop has been created
at 40695c40585943b13e3c1005648e1da4dc490542 (commit)
- Log -
commit 40695c40585943b13e3c1005648e1da4dc490542
Author: Ralf Gerlich
Date: Tue Dec 29
On Friday, January 20, 2012 07:55:24 Martin Spott wrote:
Martin Spott wrote:
Topologically cleaned CLC2000v15 is now available on the FlightGear
MapServer web map and if you download Shapefiles, you'll get them from
the revised dataset. Please let me know if you encounter technical
On Fri, Jan 20, 2012 at 12:09 AM, Martin Spott martin.sp...@mgras.netwrote:
A agree with all of the above. Creating all four edges for a stand-
alone tile sounds reasonable and creating just N/E when S/W are
available isn't that bad either. Anyhow, as far as I understand,
fgfs-construct was
Adrian Musceac wrote:
That's great news. I'm curious, what kind of elevation data are you using for
the new terrain?
In general I think I'll try to use the best I can get under a GPL-
compatible license ;-)
SRTMv3 by any chance?
Well, one day I'll have to make a decision but beforehand
Martin Spott wrote:
CLC2006v15 likewise,
BTW, here's my list of most urgent open items related to the web map
which I think are worth being addressed - maybe someone would like to
volunteer:
- Make the four input fields and the download button disappear as long
as the Download-Box layer is
On Fri, 2012-01-20 at 12:29 +, Martin Spott wrote:
Adrian Musceac wrote:
That's great news. I'm curious, what kind of elevation data are you using
for
the new terrain?
In general I think I'll try to use the best I can get under a GPL-
compatible license ;-)
SRTMv3 by any
Martin Spott wrote:
Martin Spott wrote:
Supplying the flags --xdist=19 --ydist=18 (around a center at
--lon=9.875 --lat=49.375, but there's no difference with --lon=10
--lat=49) seem to work nicely (test is still running, but looks good
so far), [...]
Test is still running and has
Curtis Olson wrote:
On Tue, Jan 17, 2012 at 11:49 AM, Martin Spott martin.sp...@mgras.netwrote:
1.) As far as I can tell there's still no reliable solution for
creating proper, smooth seams between a newly built terrain tile and
the adjacent, old tiles.
The fgfs-construct honours two flags
Hi Jason,
Jason Cox wrote:
On Tue, 2012-01-17 at 17:49 +, Martin Spott wrote:
Supplying the flags --xdist=19 --ydist=18 (around a center at
--lon=9.875 --lat=49.375, but there's no difference with --lon=10
--lat=49) seem to work nicely (test is still running, but looks good
so far), but
On Thu, Jan 19, 2012 at 4:01 PM, Martin Spott martin.sp...@mgras.netwrote:
Yup, using this Shared directory is still state-of-the-art. Anyhow,
this machinery works only in the limited case where just one or two
edges have to get seamed together - the western and the southern edge
of the new
Martin Spott wrote:
Topologically cleaned CLC2000v15 is now available on the FlightGear
MapServer web map and if you download Shapefiles, you'll get them from
the revised dataset. Please let me know if you encounter technical
mistakes in this data !
CLC2006v15 likewise,
Martin.
--
Curtis Olson wrote:
My recollection is that the original fgfs-construct created any shared
edges that weren't already created. So if free standing tile was created
before any of its neighbors, all the shared edges (and corners) should be
created: N, S, E, and W.
If that's not the case,
Martin Spott wrote:
Supplying the flags --xdist=19 --ydist=18 (around a center at
--lon=9.875 --lat=49.375, but there's no difference with --lon=10
--lat=49) seem to work nicely (test is still running, but looks good
so far), [...]
Test is still running and has produced 1.8 GByte of terrain
James Turner wrote:
Please let us know what help you need to make it happen, [...]
Just a quick message for a better understanding of where trouble is
still hiding:
1.) As far as I can tell there's still no reliable solution for
creating proper, smooth seams between a newly built terrain tile
On Tue, Jan 17, 2012 at 11:49 AM, Martin Spott martin.sp...@mgras.netwrote:
1.) As far as I can tell there's still no reliable solution for
creating proper, smooth seams between a newly built terrain tile and
the adjacent, old tiles.
The fgfs-construct honours two flags
On Tue, 2012-01-17 at 17:49 +, Martin Spott wrote:
Surprisingly there seems to be another limit with really large areas.
Supplying the flags --xdist=19 --ydist=18 (around a center at
--lon=9.875 --lat=49.375, but there's no difference with --lon=10
--lat=49) seem to work nicely (test is
James Turner wrote:
Of course, this will be fantastic. Please let us know what help you
need to make it happen, and thanks for all your long, hidden efforts
on this.
Topologically cleaned CLC2000v15 is now available on the FlightGear
MapServer web map and if you download Shapefiles, you'll
Gijs de Rooy wrote:
If not, would you mind if I copyedited some of your mail?
Please feel free to do everything what you think makes sense. I'm
having a (programming) deadline to meet until end of the week,
therefore I'm probably not going to do anything which doesn't fit into
chunks of 5
On 13 Jan 2012, at 17:46, Martin Spott wrote:
Finally 3.) As soon as the various tools are working in a predictable
manner, I'm planning to revive the central idea, the driving motivation
behind all the effort, which is to build an infrastructure for
re-compiling the respective terrain tiles
Martin wrote:
I'd like to point out that I'm now having what I think should be
topologically clean CLC2000v15 and VMap0 edition 5.0 datasets. I'll
load these into the Landcover-DB as replacements for the current VMap0
and CLC layers.
That's excellent news indeed! Would you write a short
I'd like to point out that I'm now having what I think should be
topologically clean CLC2000v15 and VMap0 edition 5.0 datasets. I'll
load these into the Landcover-DB as replacements for the current VMap0
and CLC layers.
Thanks to the great folks at GRASS GIS, most notably Markus M., the
Martin Spott wrote:
2.) Merging custom land cover data (like John Holden's great work) into
the Custom Scenery layer (at MapServer) had been failing in some
cases due to topological inconsistencies. I expect these failures
to disappear with topologically clean vector data.
Finally
Martin Spott wrote:
I've been using osm2pgsql for years for importing The Planet Dump
into PostGIS and so far I'm quite satisfied. After the bare import I'm
using a custom script to separate the various road types into distinct
tables/layers, something like:
landcover= SELECT osm_id,
Hi Peter,
what you're describing sounds familiar. Ralf and I had been observing
at least two characteristic types of failures:
1.) An airfield hole (or a road) cutting a landcover polygon into two
parts of which the (much) smaller one was left without centroid after
clipping.
2.) A centroid
Hi Martin,
I saw the experimental polygons on the mapserver. It's good to see
clipping the road against the landclass works so well. I had played with
v.buffer before, and was going to use it as a baseline to try to retain
texture coordinates in GRASS in the same way I am for ogr-decode /
Hi Peter,
Peter Sadrozinski wrote:
Have you tried to triangulate the landclass in GRASS yet? I was wondering
how well that works compared to triangleJRS.
I have to admit that I never did that myself.
At one of our meetings maybe more than two years ago Ralf presented to
me what later ended
Hi Martin,
I think I see the cause. It looks like sometimes, when a low priority
landclass is clipped against the already accumulated thin polys like roads
and steams, there could be a section that isn't removed (so only 1 region
is created when there should be 2). Because the road region is
Hi Peter,
Flightgear-commitlogs wrote:
It doesn't crash, but sometimes, polygons lose their material. I
think fixing that
should be easier than the endless massaging of data to keep good
looking data.
According to my/our (Ralf's and mine) experience loosing the material
28 matches
Mail list logo
