[GRASSLIST:5357] Re: 2 prob.: v.proj and overlapping

[Francesco Mirabella]

Hi Radim

Unfortunately I am reading your message only now.... We will send you a
sample as soon as we can,

many thanks again for your support

Francesco

On Thu, Jan 13, 2005 at 05:23:20PM +0100, Radim Blazek wrote:
> Francesco Mirabella wrote:
> >Hi radim and many thanks for your reply,
> >
> >no, we did not use the -c option because we thought that polygons should
> >be cleaned (or maybe not?)
> 
> That is correct, v.in.ogr which -c does not import polygons correctly.
> 
> The proble is surely in import, but I cann say what is the problem
> untill I see that data. Can you send me a _small_ subset of your
> dat (shp) ideally just few areas?
> 
> Radim
> 
> 
> >Francesco
> >
> >On Thu, Jan 13, 2005 at 04:04:53PM +0100, Radim Blazek wrote:
> >
> >>Have you used v.in.ogr -c?
> >>
> >>Radim
> >>
> >>Francesco Mirabella wrote:
> >>
> >>>Hi Radim and all,
> >>>
> >>>I am currently working with ivan regarding the topic of this message:
> >>>
> >>>Actually, we had some problems when reprojecting from UTM to
> >>>Gauss-Boaga as Ivan wrote before. The original map was Corinne landcover
> >>>2000 (.shp).
> >>>The problem first arised after reprojection to Gauss-Boaga so we decided
> >>>to go back to the originally imported map into UTM (corinne landcover
> >>>2000 is utm).
> >>>
> >>>The original UTM corinne was displayed well also when queried 
> >>>(d.what.vect), but when looking into it in detail with v.digit we found
> >>>that a lot of boundaries were duplicated. It means that each vertex 
> >>>snapped
> >>>over another of the same boundary, closing where the boundary start (the
> >>>start and the end of the boundary is the same!!! and also all the other
> >>>nodes).
> >>>This brings to the creation of a lot of doubled areas and their 
> >>>centroids are positionated exaclty over the double boundary...
> >>>
> >>>To try to solve this, we decided to try to delete the double areas and
> >>>tried v.clean tool=rmarea thresh=es.1(meter) in order to have the small 
> >>>double areas removed.
> >>>
> >>>Now the problem is that v.clean was still removing areas on the map but 
> >>>the process is still running after 15 hours work on a pentium 4 
> >>>processor, 512 Mb ram!
> >>>
> >>>many thanks for your help
> >>>
> >>>Francesco
> >>>
> >>>
> >>>
> >>>On Thu, Jan 13, 2005 at 12:09:23PM +0100, Radim Blazek wrote:
> >>>
> >>>
> >>>>ivan marchesini wrote:
> >>>>
> >>>>
> >>>>>Dear users...
> >>>>>I've got two problems using grass57....
> >>>>>
> >>>>>the first one:
> >>>>>I've an area vector map in UTM ED50 system (imported from a shp map)...
> >>>>>is a complex map, with a lot of boundary segments and a lot of
> >>>>>centroids... but it is quite correct because all the areas seems to
> >>>>>answer correcly to v.what.vect... and all boundaries are two areas
> >>>>>boundaries... according to v.digit..
> >>>>>I've projected it on gauss-boaga roma40 system (an italian system) 
> >>>>>using
> >>>>>v.proj...
> >>>>>now only few areas are preserved...(in the gauss-boaga system I mean)
> >>>>>and there are a lot of not correct boundaries (no area or 1 area... as
> >>>>>v.digit explain...). Consequently, also areas are not respected ....
> >>>>>can you explain me the reason of this behaviour... and how to solve the
> >>>>>problem??? thank you
> >>>>
> >>>>That is interesting. In theory, reprojection could maybe corrupt the 
> >>>>topology, but it is not probable for UTM and Gauss-Boaga on a small 
> >>>>area. Could you send me a small example (use v.in.region and v.select)
> >>>>including both PROJ_INFO?
> >>>>
> >>>>Radim
> >>>>
> >>>
> >>>
> >
> 

-- 
**********************************************
Francesco Mirabella,
Istituto Nazionale di Geofisica e Vulcanologia
Sismologia e Tettonofisica, Roma (Italy)
contact c/o:
Structural Geology and Geophysics
address: University of Perugia,
Dipartimento di Scienze della Terra
Piazza Universita', 1 06100 Perugia (Italy)
tel: ++39.(0)75.585 2651
fax: ++39.(0)75.585 2603
e-mail: mirabell at unipg.it
web: http://www.unipg.it/~mirabell/
**********************************************