Hi Marko,
> The action would be placed in the 'polygons' file
I like your idea. Generally speaking, a complex object like a way or
polygon could have actions similar to actions currently supported for
relations.
--
Best regards,
Andrzej
___
mkgmap-
Hi Andrzej,
These object aren't tagged the same way, are they? It isn't a simple
case, where information is duplicated. There will be many ways to
interpret and use this informations. For example it could be
advantageous to move tags from area to point.
Right.
AFAICT, the source of the prob
Hi Marko,
> If we think of a building, the shape of its outline is one
> feature, and the location of the main entrance is another.
These object aren't tagged the same way, are they? It isn't a simple
case, where information is duplicated. There will be many ways to
interpret and use this info
On Sun, Mar 23, 2014 at 12:39:27PM +0100, Andrzej Popowski wrote:
For example, a parking facility or a building could be tagged both
as a point at the entrance, and as an area.
This is against OSM good practice, see recommendations:
http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_elemen
Hi!
Same situation applies when a city has a point with place=city and
landuse=residential with place=city. You end up with two city points next
to each other in Garmin map.
best regards
Michal Rogala
2014-03-23 12:46 GMT+01:00 GerdP :
> Hi,
>
>
> popej wrote
> > I guess, that it's not ea
Hi,
popej wrote
> I guess, that it's not easy to reliable detect duplicates. Maybe better
> correct problem at source?
It should be easy to distinguish between POI created for areas and others.
I guess it should also be easy to detect duplicate POI (if they have
identical
entries in the index(e
Hi Marko,
> For example, a parking facility or a building could be tagged both
> as a point at the entrance, and as an area.
This is against OSM good practice, see recommendations:
http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element
I guess, that it's not easy to reliable detect dup
On Sun, Mar 23, 2014 at 12:18:16PM +1100, Brett Russell wrote:
So looks like somewhere on the line the logic in mkgmap was strengthen
to pick up what would be a logic error by having POI in polygons. Or
at least that is my feelings.
Many features can be tagged points (nodes) as well as areas
of course, add
mkgmap:area2poi=true & name!=* {delete tourism; delete amenity; delete cuisine;
delete (all other keys )) as first line in your points file (or maybe after
cites).
On 21.03.2013 14:24, Roger Calvert wrote:
Thanks, Steve. This does the job. Getting it to disappear from the m
Thanks, Steve. This does the job. Getting it to disappear from the map
but stay in the index made me think a bit - I have given it an icon
consisting of one transparent pixel. It still pops up on mouseover in
MapSource, but that is no problem.
I would like to completely remove such pois which
On 19/03/13 15:52, Roger Calvert wrote:
> When pois are added to areas for search reasons, is there any way of
> identifying them in the 'points' style file, to avoid them appearing on
> the map?
They have the extra tag:
mkgmap:area2poi=true
so you can match on that to remove the ones you do
When pois are added to areas for search reasons, is there any way of
identifying them in the 'points' style file, to avoid them appearing on
the map?
Roger
--
Roger Calvert
You should only tagg the hole polygon as restaurant etc. if the hole
polygon contains only this restaurant. Else you should tagg each
restaurant etc. as a node inside the building-polygon.
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.or
First,
thanks for the new POI generation from multipolygon and polygons.
It seams to work fine and changing my style files was easy.
There is only one thing i am not happy with:
the use of building=entrance as the default position for
the POI of a polygon.
In urban areas there are often buildings
Thanks Wanmil,
The Multipolygon zoo is also released from all its elephants ;-)
Now only one is left on a poi that I tagged with role=label, and this works
fine too.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mai
Ha, that's fun!
And the solution was quite easy to realize :-)
Have fun!
WanMil
> Good job Wanmil!
> Finally I can get rid of all the airport icons on every terminal building :-)
>
> polygon style:
> aeroway=terminal [0x13 resolution 20]
>
> points:
> aeroway=terminal& mkgmap:area2poi!=true [0
Good job Wanmil!
Finally I can get rid of all the airport icons on every terminal building :-)
polygon style:
aeroway=terminal [0x13 resolution 20]
points:
aeroway=terminal & mkgmap:area2poi!=true [0x2f04 resolution 22]
02f04 is the default Garmin airport icon but it cluttered the map before.
I
Perfect and just-in-time - thanks for implementing this.
Regards Klaus
--
View this message in context:
http://gis.638310.n2.nabble.com/add-pois-to-areas-processing-vs-point-processing-tp6885984p6886385.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
Points defined the OSM files and points generated by the
add-pois-to-areas option are processed by the same rules in the points
file. This behaviour is new since the lastest revision r2049.
So using the latest mkgmap download you should achieve the desired results.
WanMil
> Question:
> Is it
Question:
Is it possible to achieve for a point, generated by add-pois-to-areas, the
same processing as for an identical point?
point:
name: Junge
shop: bakery
Rule: shop = bakery & name = * {name '${name} (Bäckerei)'} [0x2a0d
resolution 24]
Result: Junge (Bäckerei)
closedway:
building: yes
name:
Hi!
I found some examples where an area has more than one attribute. It
seems to me that those get no POI generated if not all attributes match
a polygon and a point. I would prefer if it gets a POI if one attribute
matches.
Dani
___
mkgmap-dev maili
Am 29.01.2010 um 17:47 schrieb Christoph Wagner:
> Thilo Hannemann schrieb:
>> The reason why you need a matching polygon rule for POIs to be generated is
>> that mkgmap needs this to find out that it is a polygon.
>
> Now I really understand the problem. Would it be enough for mkgmap to specif
Thilo Hannemann schrieb:
> The reason why you need a matching polygon rule for POIs to be generated is
> that mkgmap needs this to find out that it is a polygon.
>
Now I really understand the problem. Would it be enough for mkgmap to specify a
rule in polygons-file like this:
building=*
witho
The reason why you need a matching polygon rule for POIs to be generated is
that mkgmap needs this to find out that it is a polygon.
Why is this? Because there is no way to find out whether a closed line is
actually a polygon or a line/way besides looking at the tags. From the OSM
standpoint a
Felix Hartmann schrieb:
> Well you might not like to have a POI for every polygon (what's the
> point in a POI for a city? - cities are entered as seperate points anyhow)
Ok, I see there are problems. But I thought that there is an algorithm to
check, if there exist a point in the polygon, yet t
On 28.01.2010 15:03, Christoph Wagner wrote:
Felix Hartmann schrieb:
That's because it's only a dirty hack alltogether. It would be bit
cleaner if there was a seperate file inside the style-file where one can
specify the poi to areas keys. Currently mkgmap can only know what kind
of POI t
Felix Hartmann schrieb:
> That's because it's only a dirty hack alltogether. It would be bit
> cleaner if there was a seperate file inside the style-file where one can
> specify the poi to areas keys. Currently mkgmap can only know what kind
> of POI to create, if it also has a matching Polygon. T
On 28.01.2010 13:48, Christoph Wagner wrote:
Hi list,
I found an issue with the --add-pois-to-areas option and don't know if it's a
bug or a feature.
Areas get only converted to points, if there is a matching rule in the
points-style file AND if there is a matching rule in the polygons file
Hi list,
I found an issue with the --add-pois-to-areas option and don't know if it's a
bug or a feature.
Areas get only converted to points, if there is a matching rule in the
points-style file AND if there is a matching rule in the polygons file.
I don't understand the second condition.
Imagi
Christoph Wagner schrieb:
> Hello list,
>
> I just want to produce a garmin map, where you can see all adresses
> tagged in osm, even the adresses on a building polygon for example too.
>
> So I used the --add-pois-to-areas option and wrote just one line in the
> points style file:
> addr:housenu
Hello list,
I just want to produce a garmin map, where you can see all adresses
tagged in osm, even the adresses on a building polygon for example too.
So I used the --add-pois-to-areas option and wrote just one line in the
points style file:
addr:housenumber=* {name '${name} (${addr:street} ${ad
31 matches
Mail list logo
