date:20150130

Re: [mkgmap-dev] FW: Lines distorted

2015-01-30 Thread demon.box

yes you'are right, I'm interested to straight out the line "Via Ronchi Di San
Francesco Di Paola".
would be great if you'll find something to do this.
THANKS.
--enrico




--
View this message in context: 
http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831971.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] FW: Lines distorted

2015-01-30 Thread GerdP

Hi Enrico,

okay, don't know what's wrong, the binary works for me.
In the mean time I was able to find out what data your screen shot shows.
If I got it right, you are interested in "Via Ronchi Di San Francesco Di
Paola"
which consists of many very small parts with alternating types.
Maybe this is a special case, the options don't help to straight
out these lines. 
'll have a look at this during the next days.

Gerd


demon.box wrote
> ah ok, I understand but I'm sure that I'm using your mkgmap.jar (I
> rename the normal version)





--
View this message in context: 
http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831970.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] FW: Lines distorted

2015-01-30 Thread demon.box

ah ok, I understand but I'm sure that I'm using your mkgmap.jar (I rename
the normal version)



--
View this message in context: 
http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831965.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit: r3433: quote pipe symbol in doc

2015-01-30 Thread svn commit


Version mkgmap-r3433 was committed by gerd on Fri, 30 Jan 2015

quote pipe symbol in doc
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Patch: New filter "not-contained"

2015-01-30 Thread Maxim Düster


Hi, Gerd,

 

I just saw in the generated style documentation that I overlooked to escape the pipe symbol (|) in the rule-filters.txt. Here the small correction. Please commit it to the trunk.

 

Max

 

Gesendet: Freitag, 30. Januar 2015 um 16:35 Uhr
Von: GerdP 
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Patch: New filter "not-contained"

Hi Max,

okay, thanks for the explanation. I think I understand now.
I think we can say that your patch is also a correction and
the "side effect" is in fact the better solution.

I've committed the patch with r3422.

Gerd



"Maxim Düster" wrote
> Hi, Gerd,
>
>  
>
> well, it's indeed not so easy to find an example. In most cases you
> won't see any difference because almost no existent filter uses the
> second parameter in the filter()/doFilter() method. The only one using it,
> besides the proposed new filter, is the 'not-equal' filter. The
> example I found for using it inside the apply{} block is a bit artificial
> and probably not really meaningful, but I hope, it gives the idea.
>
> Assume, you want to find and visualize a specifical type of errors in
> data, namely streets being part of an associatedStreet relation but having
> a different name than the relation itself. To get this, you could do in
> relations file something like:
>
>  
>
> type=associatedStreet & name=* {
>     apply {
>         set
> nameInRelation='${name|not-equal:name}';
>     }
> }
>
>  
>
> where you want to compare the relation's name with the street's
> name and to remember the relation's name if it's different.
>
> Then, in lines file, you could write something like
>
>  
>
>
> highway=* & nameInRelation=* [...]
>
> 
> name=* { name '${name}/${nameInRelation}' }
>
>  
>
> to highlight the differences. So, and now, with the current mkgmap code
> both "name"s referenced in the 'set' command are the
> same, namely it's the name of the relation. You cannot pass the
> current street's name to the filter. After running mkgmap you get a
> map without any street as for every street holds name=name and so
> nameInRelation is not set.
>
>  
>
> You could also try to pass a differently named tag to the filter by saving
> the street's name in a temporary tag, like:
>
>  
>
> type=associatedStreet & name=* {
>     apply {
>
>         set myname='$(name)';
>         set
> nameInRelation='${name|not-equal:myname}';
>     }
> }
>
>
>
>  
>
> But in this case, the tag 'myname' would also be looked for in the
> relation, not in the street's tags, and as the relation doesn't
> have such a tag, nameInRelation is always set to the relation's name
> and so you see in your map all the streets, not only the erroneous ones.
> So, either all or no at all.
>
>  
>
> With the proposed change, however, the filter gets a local element as a
> second parameter in doFilter(), so in both cases the name of the relation
> would be compared to the (local) tags of the current street (either name
> or myname) and you would get only streets with errors in the map.
>
> The new filter is specifically designed for using in the apply{} block, so
> it necessarily needs an access to the local object.
>
>  
>
> So, to summarize my reasoning: the functionality of no existent filter
> would break after the patch (almost all filters would not see any
> difference, one would potentially benefit from the change and one requires
> it). Writers of new filters would not, in my opinion, have any troubles
> with it, too. If they would need a local element, they get it for free. If
> they would need a global element, one can always save global tags in the
> local element and then call the filter with the local element.
>
>  
>
> What do you think about it now? Could I convince you? :)
>
>  
>
> Max
>
>  
>
>
> Gesendet: Donnerstag, 29. Januar 2015 um 23:31 Uhr
> Von: GerdP <

> gpetermann_muenchen@

> >
> An: 

> mkgmap-dev@.org

>
> Betreff: Re: [mkgmap-dev] Patch: New filter "not-contained"
>
> Hi Maxim,
>
> I tried to find out if the patch has a side effect, but
> I failed. From your description I understand that
> I should be able to produce different results (not
> using the new filter, just something that workded before)
>
> Can you give an example where I should find a difference?
>
> Gerd
>
>
> "Maxim Düster" wrote
> > Hi, Gerd,
> >
> >  
> >
> > I think, there shouldn't be a problem. Actually, if you are
> using a
> > filter inside of the apply{} block, you would presumably like to be
> able
> > to access the current element from the filter. At the moment you
> don't
> > have such a possibility at all.
> >
> > If though there will be need to pass a tag from the global relation
> to the
> > filter, one can always assign a global tag to a temporary local tag
> before
> > calling the filter with this local tag.
> >
> > So, in my mind, nothing should go wrong here. Perhaps someone else
> can say
> > something more regarding this issue.
> >
> >  
> >
> > Max
> >
> >  
> >
> > G

Re: [mkgmap-dev] FW: Lines distorted

2015-01-30 Thread GerdP

Hi Enrico,

please double check. Every mkgmap version will accept these options because
they start with
"x-" 

Gerd


demon.box wrote
> yes I use your patched binary because it accept the new options but I see
> the same img file size... and the same rendered result.
 




--
View this message in context: 
http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831960.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] FW: Lines distorted

2015-01-30 Thread demon.box

yes I use your patched binary because it accept the new options but I see the
same img file size... and the same rendered result.

 




--
View this message in context: 
http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831958.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Patch: New filter "not-contained"

2015-01-30 Thread Maxim Düster


Hi, Gerd,

 

glad to hear it) Thank you

 

Max

 

Gesendet: Freitag, 30. Januar 2015 um 16:35 Uhr
Von: GerdP 
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Patch: New filter "not-contained"

Hi Max,

okay, thanks for the explanation. I think I understand now.
I think we can say that your patch is also a correction and
the "side effect" is in fact the better solution.

I've committed the patch with r3422.

Gerd



"Maxim Düster" wrote
> Hi, Gerd,
>
>  
>
> well, it's indeed not so easy to find an example. In most cases you
> won't see any difference because almost no existent filter uses the
> second parameter in the filter()/doFilter() method. The only one using it,
> besides the proposed new filter, is the 'not-equal' filter. The
> example I found for using it inside the apply{} block is a bit artificial
> and probably not really meaningful, but I hope, it gives the idea.
>
> Assume, you want to find and visualize a specifical type of errors in
> data, namely streets being part of an associatedStreet relation but having
> a different name than the relation itself. To get this, you could do in
> relations file something like:
>
>  
>
> type=associatedStreet & name=* {
>     apply {
>         set
> nameInRelation='${name|not-equal:name}';
>     }
> }
>
>  
>
> where you want to compare the relation's name with the street's
> name and to remember the relation's name if it's different.
>
> Then, in lines file, you could write something like
>
>  
>
>
> highway=* & nameInRelation=* [...]
>
> 
> name=* { name '${name}/${nameInRelation}' }
>
>  
>
> to highlight the differences. So, and now, with the current mkgmap code
> both "name"s referenced in the 'set' command are the
> same, namely it's the name of the relation. You cannot pass the
> current street's name to the filter. After running mkgmap you get a
> map without any street as for every street holds name=name and so
> nameInRelation is not set.
>
>  
>
> You could also try to pass a differently named tag to the filter by saving
> the street's name in a temporary tag, like:
>
>  
>
> type=associatedStreet & name=* {
>     apply {
>
>         set myname='$(name)';
>         set
> nameInRelation='${name|not-equal:myname}';
>     }
> }
>
>
>
>  
>
> But in this case, the tag 'myname' would also be looked for in the
> relation, not in the street's tags, and as the relation doesn't
> have such a tag, nameInRelation is always set to the relation's name
> and so you see in your map all the streets, not only the erroneous ones.
> So, either all or no at all.
>
>  
>
> With the proposed change, however, the filter gets a local element as a
> second parameter in doFilter(), so in both cases the name of the relation
> would be compared to the (local) tags of the current street (either name
> or myname) and you would get only streets with errors in the map.
>
> The new filter is specifically designed for using in the apply{} block, so
> it necessarily needs an access to the local object.
>
>  
>
> So, to summarize my reasoning: the functionality of no existent filter
> would break after the patch (almost all filters would not see any
> difference, one would potentially benefit from the change and one requires
> it). Writers of new filters would not, in my opinion, have any troubles
> with it, too. If they would need a local element, they get it for free. If
> they would need a global element, one can always save global tags in the
> local element and then call the filter with the local element.
>
>  
>
> What do you think about it now? Could I convince you? :)
>
>  
>
> Max
>
>  
>
>
> Gesendet: Donnerstag, 29. Januar 2015 um 23:31 Uhr
> Von: GerdP <

> gpetermann_muenchen@

> >
> An: 

> mkgmap-dev@.org

>
> Betreff: Re: [mkgmap-dev] Patch: New filter "not-contained"
>
> Hi Maxim,
>
> I tried to find out if the patch has a side effect, but
> I failed. From your description I understand that
> I should be able to produce different results (not
> using the new filter, just something that workded before)
>
> Can you give an example where I should find a difference?
>
> Gerd
>
>
> "Maxim Düster" wrote
> > Hi, Gerd,
> >
> >  
> >
> > I think, there shouldn't be a problem. Actually, if you are
> using a
> > filter inside of the apply{} block, you would presumably like to be
> able
> > to access the current element from the filter. At the moment you
> don't
> > have such a possibility at all.
> >
> > If though there will be need to pass a tag from the global relation
> to the
> > filter, one can always assign a global tag to a temporary local tag
> before
> > calling the filter with this local tag.
> >
> > So, in my mind, nothing should go wrong here. Perhaps someone else
> can say
> > something more regarding this issue.
> >
> >  
> >
> > Max
> >
> >  
> >
> > Gesendet: Donnerstag, 29. Januar 2015 um 18:30 Uhr
> > Von: GerdP <
>
> > gpetermann_muenchen@
>
> > >
> > An: 
>
> > mkgmap-dev@.or

Re: [mkgmap-dev] FW: Lines distorted

2015-01-30 Thread GerdP

Hi Enrico,

I just tried the binary. I see different img file size with parameter
--x-waf-max-error-percentage=200,
so I think it works as expected. Are you sure that you use the patched
binary?

Gerd


demon.box wrote
> ok I found the problem with my style... sorry again.
> then I make some test but unfortunately I can't find any difference with
> many values of the new options...
> thanks
> --enrico





--
View this message in context: 
http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831948.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit: r3432: mkgmap_filter_not-contained.patch by Maxim Düster.

2015-01-30 Thread svn commit


Version mkgmap-r3432 was committed by gerd on Fri, 30 Jan 2015

mkgmap_filter_not-contained.patch by Maxim Düster.

Implements the new not-contained style filter.
Can be used to test if a tag with a list of values already contains a
given value.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Patch: New filter "not-contained"

2015-01-30 Thread GerdP

Hi Max,

okay, thanks for the explanation. I think I understand now. 
I think we can say that your patch is also a correction and 
the "side effect" is in fact the better solution.

I've committed the patch with r3422.

Gerd



"Maxim Düster" wrote
> Hi, Gerd, 
> 
>   
> 
> well, it's indeed not so easy to find an example. In most cases you
> won't see any difference because almost no existent filter uses the
> second parameter in the filter()/doFilter() method. The only one using it,
> besides the proposed new filter, is the 'not-equal' filter. The
> example I found for using it inside the apply{} block is a bit artificial
> and probably not really meaningful, but I hope, it gives the idea. 
> 
> Assume, you want to find and visualize a specifical type of errors in
> data, namely streets being part of an associatedStreet relation but having
> a different name than the relation itself. To get this, you could do in
> relations file something like: 
> 
>   
> 
> type=associatedStreet & name=* { 
>     apply { 
>         set
> nameInRelation='${name|not-equal:name}'; 
>     } 
> } 
> 
>   
> 
> where you want to compare the relation's name with the street's
> name and to remember the relation's name if it's different. 
> 
> Then, in lines file, you could write something like 
> 
>   
> 
> 
> highway=* & nameInRelation=* [...] 
> 
>  
> name=* { name '${name}/${nameInRelation}' } 
> 
>   
> 
> to highlight the differences. So, and now, with the current mkgmap code
> both "name"s referenced in the 'set' command are the
> same, namely it's the name of the relation. You cannot pass the
> current street's name to the filter. After running mkgmap you get a
> map without any street as for every street holds name=name and so
> nameInRelation is not set. 
> 
>   
> 
> You could also try to pass a differently named tag to the filter by saving
> the street's name in a temporary tag, like: 
> 
>   
> 
> type=associatedStreet & name=* { 
>     apply { 
> 
>         set myname='$(name)'; 
>         set
> nameInRelation='${name|not-equal:myname}'; 
>     } 
> } 
> 
> 
> 
>   
> 
> But in this case, the tag 'myname' would also be looked for in the
> relation, not in the street's tags, and as the relation doesn't
> have such a tag, nameInRelation is always set to the relation's name
> and so you see in your map all the streets, not only the erroneous ones.
> So, either all or no at all. 
> 
>   
> 
> With the proposed change, however, the filter gets a local element as a
> second parameter in doFilter(), so in both cases the name of the relation
> would be compared to the (local) tags of the current street (either name
> or myname) and you would get only streets with errors in the map. 
> 
> The new filter is specifically designed for using in the apply{} block, so
> it necessarily needs an access to the local object. 
> 
>   
> 
> So, to summarize my reasoning: the functionality of no existent filter
> would break after the patch (almost all filters would not see any
> difference, one would potentially benefit from the change and one requires
> it). Writers of new filters would not, in my opinion, have any troubles
> with it, too. If they would need a local element, they get it for free. If
> they would need a global element, one can always save global tags in the
> local element and then call the filter with the local element. 
> 
>   
> 
> What do you think about it now? Could I convince you? :) 
> 
>   
> 
> Max 
> 
>   
> 
> 
> Gesendet: Donnerstag, 29. Januar 2015 um 23:31 Uhr 
> Von: GerdP <

> gpetermann_muenchen@

> > 
> An: 

> mkgmap-dev@.org

>  
> Betreff: Re: [mkgmap-dev] Patch: New filter "not-contained" 
> 
> Hi Maxim, 
> 
> I tried to find out if the patch has a side effect, but 
> I failed. From your description I understand that 
> I should be able to produce different results (not 
> using the new filter, just something that workded before) 
> 
> Can you give an example where I should find a difference? 
> 
> Gerd 
> 
> 
> "Maxim Düster" wrote 
> > Hi, Gerd, 
> > 
> >   
> > 
> > I think, there shouldn't be a problem. Actually, if you are
> using a 
> > filter inside of the apply{} block, you would presumably like to be
> able 
> > to access the current element from the filter. At the moment you
> don't 
> > have such a possibility at all. 
> > 
> > If though there will be need to pass a tag from the global relation
> to the 
> > filter, one can always assign a global tag to a temporary local tag
> before 
> > calling the filter with this local tag. 
> > 
> > So, in my mind, nothing should go wrong here. Perhaps someone else
> can say 
> > something more regarding this issue. 
> > 
> >   
> > 
> > Max 
> > 
> >   
> > 
> > Gesendet: Donnerstag, 29. Januar 2015 um 18:30 Uhr 
> > Von: GerdP < 
> 
> > gpetermann_muenchen@ 
> 
> > > 
> > An:  
> 
> > mkgmap-dev@.org 
> 
> > 
> > Betreff: Re: [mkgmap-dev] Patch: New filter
> "not-containe

Re: [mkgmap-dev] Patch: New filter "not-contained"

2015-01-30 Thread Maxim Düster


Hi, Gerd,

 

well, it's indeed not so easy to find an example. In most cases you won't see any difference because almost no existent filter uses the second parameter in the filter()/doFilter() method. The only one using it, besides the proposed new filter, is the 'not-equal' filter. The example I found for using it inside the apply{} block is a bit artificial and probably not really meaningful, but I hope, it gives the idea.

Assume, you want to find and visualize a specifical type of errors in data, namely streets being part of an associatedStreet relation but having a different name than the relation itself. To get this, you could do in relations file something like:

 

type=associatedStreet & name=* {
    apply {
        set nameInRelation='${name|not-equal:name}';
    }
}

 

where you want to compare the relation's name with the street's name and to remember the relation's name if it's different.

Then, in lines file, you could write something like

 


highway=* & nameInRelation=* [...]


name=* { name '${name}/${nameInRelation}' }

 

to highlight the differences. So, and now, with the current mkgmap code both "name"s referenced in the 'set' command are the same, namely it's the name of the relation. You cannot pass the current street's name to the filter. After running mkgmap you get a map without any street as for every street holds name=name and so nameInRelation is not set.

 

You could also try to pass a differently named tag to the filter by saving the street's name in a temporary tag, like:

 

type=associatedStreet & name=* {
    apply {

        set myname='$(name)';
        set nameInRelation='${name|not-equal:myname}';
    }
}



 

But in this case, the tag 'myname' would also be looked for in the relation, not in the street's tags, and as the relation doesn't have such a tag, nameInRelation is always set to the relation's name and so you see in your map all the streets, not only the erroneous ones. So, either all or no at all.

 

With the proposed change, however, the filter gets a local element as a second parameter in doFilter(), so in both cases the name of the relation would be compared to the (local) tags of the current street (either name or myname) and you would get only streets with errors in the map.

The new filter is specifically designed for using in the apply{} block, so it necessarily needs an access to the local object.

 

So, to summarize my reasoning: the functionality of no existent filter would break after the patch (almost all filters would not see any difference, one would potentially benefit from the change and one requires it). Writers of new filters would not, in my opinion, have any troubles with it, too. If they would need a local element, they get it for free. If they would need a global element, one can always save global tags in the local element and then call the filter with the local element.

 

What do you think about it now? Could I convince you? :)

 

Max

 


Gesendet: Donnerstag, 29. Januar 2015 um 23:31 Uhr
Von: GerdP 
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Patch: New filter "not-contained"

Hi Maxim,

I tried to find out if the patch has a side effect, but
I failed. From your description I understand that
I should be able to produce different results (not
using the new filter, just something that workded before)

Can you give an example where I should find a difference?

Gerd


"Maxim Düster" wrote
> Hi, Gerd,
>
>  
>
> I think, there shouldn't be a problem. Actually, if you are using a
> filter inside of the apply{} block, you would presumably like to be able
> to access the current element from the filter. At the moment you don't
> have such a possibility at all.
>
> If though there will be need to pass a tag from the global relation to the
> filter, one can always assign a global tag to a temporary local tag before
> calling the filter with this local tag.
>
> So, in my mind, nothing should go wrong here. Perhaps someone else can say
> something more regarding this issue.
>
>  
>
> Max
>
>  
>
> Gesendet: Donnerstag, 29. Januar 2015 um 18:30 Uhr
> Von: GerdP <

> gpetermann_muenchen@

> >
> An: 

> mkgmap-dev@.org

>
> Betreff: Re: [mkgmap-dev] Patch: New filter "not-contained"
>
> Hi Max,
>
> not sure. What will happen if one uses another filter in the relations
> file?
>
> Gerd
>
>
> "Maxim Düster" wrote
> > Hi, Gerd,
> >
> >  
> >
> > the change is caused by the fact that the filter was thought
> primarily for
> > working in relations file inside of the apply{} block and needs that
> the
> > tag given as last parameter is a local tag of the element being
> processed
> > (e.g. a way). But the old code line says: "value =
> > filter.filter(tagval,el);", 'el' being the
> parent relation
> > the way is in. That is, in the filter I only have an access to the
> > (global) relation's tags, but what I actually need are the
> tags of the
> > (local) element being currently processed.
>

Re: [mkgmap-dev] FW: Lines distorted

2015-01-30 Thread demon.box

ok I found the problem with my style... sorry again.
then I make some test but unfortunately I can't find any difference with
many values of the new options...
thanks
--enrico




--
View this message in context: 
http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831940.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] FW: Lines distorted

2015-01-30 Thread GerdP

Hi Enrico,

I have no idea. The patch is not likely to cause that, so probably your 
test environment is the problem. You can try any combination of the three
options, but not all of them will produce good results.

Gerd


demon.box wrote
> sorry, thanks very much for your patience, now I understand, it's just
> because the new 3 options are usable alternatively, right?
> 
> I make some test but the new mkgmap ignore my style for lines, why?
 




--
View this message in context: 
http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831937.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] FW: Lines distorted

2015-01-30 Thread demon.box

sorry, thanks very much for your patience, now I understand, it's just
because the new 3 options are usable alternatively, right?

I make some test but the new mkgmap ignore my style for lines, why?

 





--
View this message in context: 
http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831936.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] leading and trailing spaces

2015-01-30 Thread Mike Baggaley

Hi Gerd, good point. There isn't any single place that can fix for all the
input formats as far as I can see. The attached patch separately updates
each of the readers.

Regards,
Mike

From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 29 January 2015 15:03
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] leading and trailing spaces

Hi Mike,

I'd prefer a patch that changes the behaviour also for xml and o5m input,
not just for *.pbf.  Maybe you find a place where this can be done once for
all sources?

Gerd
From: m...@tvage.co.uk  
To: mkgmap-dev@lists.mkgmap.org.uk  
Date: Thu, 29 Jan 2015 12:10:40 +
Subject: Re: [mkgmap-dev] leading and trailing spaces
Hi Gerd, you are right; trim() removes all leading and trailing characters
that are less than 0x20. However, the place I mention is reading the raw OSM
data before any styles have been applied, so this should not be a problem.

I agree with Paco that ideally the OSM data should be corrected, but that
will always be playing catch up, so I think it is best to also remove them
in the mkgmap processing. I have corrected a number of local ones in OSM,
but there are too many to correct them all manually.

I've attached a patch that seems to be OK to me. Please give it a try.

Regards,
Mike

-Original Message-
From: GerdP [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 29 January 2015 06:18
To: mkgmap-dev@lists.mkgmap.org.uk  
Subject: Re: [mkgmap-dev] leading and trailing spaces

Hi Mike,

I can't find it now, but I seem to remember a comment that
trim() should be used with great care as it removes the highway shield
codes.

Gerd

Mike Baggaley wrote
> Good evening all,
> 
> I've noticed that there are a number of unwanted leading and trailing
> spaces
> in OSM data. You can get a list of the ones on the name field using the
> following:
> 
> name~'.* ' {echotags "name ends with a space"}
> name~' .*' {echotags "name starts with a space"}
> 
> I can't see any facility in mkgmap to remove these, and was wondering
> whether the best way would be simply to code them out by replacing the
> following line in parseDense, parseNodes, ParseWays and parseRelations:
> 
> String val = getStringById(...);
> 
> With
> 
> String val = getStringById(...).trim();
> 
> I can't think of any reason why a value would need to start or end with a
> space, so it seems reasonable to just remove them. Are there any other
> suggestions, or reasons why this should not be done?
> 
> Regards,
> Mike
> 
> ___
> mkgmap-dev mailing list

> mkgmap-dev@.org  

> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

--
View this message in context:
http://gis.19327.n5.nabble.com/leading-and-trailing-spaces-tp5831778p5831782
.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.

___ mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk 
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

trimspaces2.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] patches

2015-01-30 Thread GerdP

Hi Steve,

again and again users report that they don't
know what to do with patches.
Do you think it would be possible to implement
a service on http://www.mkgmap.org.uk/
which allows to upload a patch to get a binary?

Gerd



--
View this message in context: 
http://gis.19327.n5.nabble.com/patches-tp5831932.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] FW: Lines distorted

2015-01-30 Thread GerdP

Hi Enrico,

please read the complete post, it contains a link to the binary as well.

Gerd


demon.box wrote
> sorry, how can I apply your patch?
> I found the command:
> 
> patch < patch-name
> 
> but I don't understand very much how I have to apply it...
> thanks very much.
> --enrico





--
View this message in context: 
http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831930.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] FW: Lines distorted

2015-01-30 Thread demon.box

sorry, how can I apply your patch?
thanks very much.
--enrico




--
View this message in context: 
http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831926.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] FW: Lines distorted

2015-01-30 Thread Gerd Petermann

Hi Enrico,

I forgot to mention that the options are not used for shapes, only for lines.

Gerd


From: gpetermann_muenc...@hotmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Date: Fri, 30 Jan 2015 10:47:07 +0100
Subject: Re: [mkgmap-dev] FW:  Lines distorted







Hi Enrico,

attached is a quick patch that implements three new experimental options:
--x-waf-max-bearing-error=15
--x-waf-max-angle=3
--x-waf-max-error-percentage=100

Meaning:
--x-waf-max-bearing-error=15
The algo calculates the delta of the displayed baring and the real
bearing in OSM. If the delta is larger than this, it tries to correct something.
Try values between 10 and 20.

--x-waf-max-angle=3
This is used to detect obsolete points.
If the 3 consecutive points (P1,P2,P3) in a line form an angle < 
x-waf-max-angle,
it is a candidate for removal. The point P2 is removed
if the distance to the straight line between P1 and P3 is small enough.
A higher value means that more points may be removed.
Reasonable values are probably between 1 and 5.

--x-waf-max-error-percentage=100
This value is used in the method that decides if the distance to the straight
line is small enough. A higher value means more points are removed.
Reasonable values are probably between 50 and 200.

The binary based on r3430 is here:
http://files.mkgmap.org.uk/download/243/mkgmap.jar


If you find better values than the defaults, please let us know. The defaults
are a compromize of calculation time and quality.

Gerd



> Date: Fri, 30 Jan 2015 01:57:31 -0700
> From: e.rossin...@alice.it
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] FW:  Lines distorted
> 
> ehm, I don't know how to modify the java source and compile my own library...
> 
> 
> 
> --
> View this message in context: 
> http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831910.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

  

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
  ___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] FW: Lines distorted

2015-01-30 Thread Gerd Petermann




Hi Enrico,

attached is a quick patch that implements three new experimental options:
--x-waf-max-bearing-error=15
--x-waf-max-angle=3
--x-waf-max-error-percentage=100

Meaning:
--x-waf-max-bearing-error=15
The algo calculates the delta of the displayed baring and the real
bearing in OSM. If the delta is larger than this, it tries to correct something.
Try values between 10 and 20.

--x-waf-max-angle=3
This is used to detect obsolete points.
If the 3 consecutive points (P1,P2,P3) in a line form an angle < 
x-waf-max-angle,
it is a candidate for removal. The point P2 is removed
if the distance to the straight line between P1 and P3 is small enough.
A higher value means that more points may be removed.
Reasonable values are probably between 1 and 5.

--x-waf-max-error-percentage=100
This value is used in the method that decides if the distance to the straight
line is small enough. A higher value means more points are removed.
Reasonable values are probably between 50 and 200.

The binary based on r3430 is here:
http://files.mkgmap.org.uk/download/243/mkgmap.jar


If you find better values than the defaults, please let us know. The defaults
are a compromize of calculation time and quality.

Gerd



> Date: Fri, 30 Jan 2015 01:57:31 -0700
> From: e.rossin...@alice.it
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] FW:  Lines distorted
> 
> ehm, I don't know how to modify the java source and compile my own library...
> 
> 
> 
> --
> View this message in context: 
> http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831910.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

  

options-for-WrongAngleFixer-v1.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] FW: Lines distorted

2015-01-30 Thread demon.box

ehm, I don't know how to modify the java source and compile my own library...



--
View this message in context: 
http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831910.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] FW: Lines distorted

2015-01-30 Thread Gerd Petermann

Hi Enrico,

you have to modify the java sources and compile your own binary.
If you can't do that I can post a quick patch to implement
some options for that.

Gerd

> Date: Fri, 30 Jan 2015 01:49:36 -0700
> From: e.rossin...@alice.it
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] FW:  Lines distorted
> 
> Hi GerdP, excuse me, how I can concretely apply the
> MAX_DIFF_ANGLE_STRAIGHT_LINE = 3 parameteres?
> Thanks.
> --enrico
> 
> 
> 
> 
> --
> View this message in context: 
> http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831907.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
  ___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] FW: Lines distorted

2015-01-30 Thread demon.box

Hi GerdP, excuse me, how I can concretely apply the
MAX_DIFF_ANGLE_STRAIGHT_LINE = 3 parameteres?
Thanks.
--enrico




--
View this message in context: 
http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831907.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Distorted lines

2015-01-30 Thread nwillink

Hi Gerd

Sounds painful ; I like the analogy!



--
View this message in context: 
http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831903.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Distorted lines

2015-01-30 Thread Gerd Petermann

Hi Nick,

I think we still can improve distorted shapes, but lines
are pretty to close to what is possible.
I think of the Garmin format as a bed of nails.
Near the equator the nails have a distance of ~2.3 m
with resolution 24. If you go north or south, the horizontal distance 
decreases.
Drawing a line on this bed of nails is like
connecting some of the nails with a rubber band.

Shapes are more complicated than lines because 
you may not want to produce gaps between them
in some cases, e.g. with buildings.

Gerd

> Date: Fri, 30 Jan 2015 01:10:41 -0700
> From: o...@pinns.co.uk
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] Distorted lines
> 
> I know this has been discussed a lot and it is annoying to see these
> distortions but having seen Garmin's  City Navigator maps with the same
> problem, I fear there isn't much more we can expect of mkgmap...?
> 
> 
> 
> --
> View this message in context: 
> http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831896.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
  ___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Distorted lines

2015-01-30 Thread nwillink

I know this has been discussed a lot and it is annoying to see these
distortions but having seen Garmin's  City Navigator maps with the same
problem, I fear there isn't much more we can expect of mkgmap...?



--
View this message in context: 
http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831896.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] FW: Lines distorted

2015-01-30 Thread Gerd Petermann

From: gpetermann_muenc...@hotmail.com
To: daveswarth...@gmail.com
Subject: RE: [mkgmap-dev] Lines distorted
Date: Fri, 30 Jan 2015 09:02:45 +0100

Hi Dave,

up to now the reduce-point-xxx options are used for the DouglasPeuckerFilter
which smoothes lines at lower resolutions. They are ignored for resolution 24,
in which the WrongAngleFixer is used to guess how an object can be placed on
the Garmin raster so that it looks as much as possible like the OSM described by
the OSM data. If you want to play with that:
The WrongAngleFixer has a few constants,
e.g. you may increase the value 
MAX_DIFF_ANGLE_STRAIGHT_LINE = 3;
or change the method calcMaxErrorDistance()
to allow larger errors.

Gerd

From: daveswarth...@gmail.com
Date: Fri, 30 Jan 2015 07:14:07 +0700
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Lines distorted

I want to continue Enrico's questioning a bit. I have a similar issue with the 
way polygons display on my Garmin device. What appears as a smooth curve on the 
OSM slippy map are very blocky on the device. I have played with the 
reduce-point-density=4 and reduce-point-density-polygon=8 parameters in an 
attempt to smooth those curves but they seem to have no effect. I can live with 
the distortion but I wonder, what do these two parameters actually control?
Cheers,Dave
On Fri, Jan 30, 2015 at 12:22 AM, Andrzej Popowski  wrote:
Hi Enrico,

Garmin maps have limited resolution, about 2.4m. One can't draw precisely a 
line, which length is near to this resolution.

You can try to assign the same Garmin object type to all these segments, then 
probably mkgmap will be able to merge them and smooth.

-- 

Best regards,

Andrzej

___

mkgmap-dev mailing list

mkgmap-dev@lists.mkgmap.org.uk

http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
  ___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] FW: Lines distorted

Re: [mkgmap-dev] FW: Lines distorted

Re: [mkgmap-dev] FW: Lines distorted

[mkgmap-dev] Commit: r3433: quote pipe symbol in doc

Re: [mkgmap-dev] Patch: New filter "not-contained"

Re: [mkgmap-dev] FW: Lines distorted

Re: [mkgmap-dev] FW: Lines distorted

Re: [mkgmap-dev] Patch: New filter "not-contained"

Re: [mkgmap-dev] FW: Lines distorted

[mkgmap-dev] Commit: r3432: mkgmap_filter_not-contained.patch by Maxim Düster.

Re: [mkgmap-dev] Patch: New filter "not-contained"

Re: [mkgmap-dev] Patch: New filter "not-contained"

Re: [mkgmap-dev] FW: Lines distorted

Re: [mkgmap-dev] FW: Lines distorted

Re: [mkgmap-dev] FW: Lines distorted

Re: [mkgmap-dev] leading and trailing spaces

[mkgmap-dev] patches

Re: [mkgmap-dev] FW: Lines distorted

Re: [mkgmap-dev] FW: Lines distorted

Re: [mkgmap-dev] FW: Lines distorted

Re: [mkgmap-dev] FW: Lines distorted

Re: [mkgmap-dev] FW: Lines distorted

Re: [mkgmap-dev] FW: Lines distorted

Re: [mkgmap-dev] FW: Lines distorted

Re: [mkgmap-dev] Distorted lines

Re: [mkgmap-dev] Distorted lines

Re: [mkgmap-dev] Distorted lines

[mkgmap-dev] FW: Lines distorted

28 matches

Site Navigation

Mail list logo

Footer information