[LaurentG]

Hi Christian (and EMUX),

FYI, not only „place_of_worship“ were affected by the filter. It was also removing the elementary school that is just beside the „Sainte-Catherine“ church, in Briançon.
This school is now present.

I’m convinced that filter was initially designed „for good reasons“, but actually, we have the proof it is useless and first of all very annoying.

And I just saw that the Alps-West.Poi has been also regenerated (did you regenerate all poi files ?).
Thank you so much for that !

[Emux]

The tests should be done with the complete poi files of Germany and France.
Or the largest split you have for these countries.
i.e. test the largest poi files

Christian, have you tested these 2 large poi files without filter?
What is the amount of poi with and without the filter?

---

Cruiser and Mapsforge developer

[LaurentG]

For France-South.Poi (that is the largest split of France, and maybe ? the largest of all), you have the figures of
– file size
– number of POI
before and after in my post above :
422 Mb vs. 410 Mb
1822767 POI vs. 1777990

[ChristianK]

Hi Emux
I don’t have France and Germany as complete Maps.
However I will try to make a test map of Germany incl Netherlands.
This should be the worst case.

But:
I do a Lot of preprocessing bevor feeding the osm data onto the poiwriter mainly clearing out not needed tags. So the dataset is essentially reduced bevor Rendering.

If someone renders POIs with whole unfiltered dataset there may be problems.

Best regards
Christian

[ChristianK]

So, I’m back in the office….

Looking at the logs:
There were rare Problems with PoisV2 (poi-writer-0.16) Germany_North.
Sometimes the script startet the writer over cause of faulty exit code.
So IMO there _is_ a rare problem but managable by taking care of the exit code/errorlevel.

An other aproach would be to reduce Poi/Ways to Nodes in final preprozessing (as I already do it with Relation/Pois):

osmconvert poi_base_rel_temp.osm –all-to-nodes –object-type-offset=15200000000+1 -o=temp.osm

.. and drop nodes/ways

So: Split already cleaned osm_poi_base into:
– Node/Pois – drop-ways -drop-relations > poi_node_nodes.osm
– Way/Pois -drop-relations / -all2nodes / – drop-nodes > poi_way_nodes.osm (start with base ID ++)
– Rel/Pois -all2nodes (base ID from step 2 ++/ -drop-ways -drop-nodes > poi_rel_nodes.osm

merge all poi_*_nodes.osm = POI file with all objects as pure NODEs

This would mean: all Poi/Ways included (as NODES), no overhead.
If there are issues with routers like BRouter?? – Should be tested…..
Only issue: overlapping ID’s should be avoided.
However – within POI-Files its managable.

So: Yes there is an issue with full ways in poi-Writer but it could be managed with ease w/o skipping lots of POIs

The complete run with poi-writer with all 270 Maps in 8 Threads in poi-writer 0.26 with full ways showed not even one problem.

So I will stay with the current workflow and trap exit code of the the poi-writer as usual.

[Emux]

Christian thanks for the info!

.. and drop nodes/ways

Doesn’t this mean missing POI ?

We prefer any improvements to be done in the writer code,
so poi-writer can be used directly with Geofabrik downloads by all users,
without having to use other tools to modify the osm files.

This is the purpose of the filter option, that obviously can be improved.

---

Cruiser and Mapsforge developer

1 Teilnehmer(n) gefällt dieser Beitrag

ChristianK

[mbe57]

Wasn’t the trap here that that behaviour went from optional, default off to default on, which kicked the ways with tagged nodes in it?
Then it just comes to set this filter as explicitly off, like Christian already did very quickly.

[LaurentG]

I ‚m not skilled enough to give a technical advice, but I can give an important „end user advice“ :
Please do all what is feasible to avoid omission of important POIs, as it was the case with the filter.

Many thanks in advance !

[LaurentG]

One new remark for Christian (and maybe also for EMUX ?)

Even after de-activating the filter, some POIs are still missing.

If I consider (as a matter of example) the main church of Briançon (France, Hautes-Alpes, 44.90017674N-6.64270648E), it was not in the POI file due to the filter, because two Artworks are defined on two nodes belonging to the way describing the church (its building). These two artworks actually exist in the true life, and are really interesting. Have them as POI is of real interest.
With the filter, neither the church, nor none of the artworks were in the file.

Since you deactivated the filter, the church itself is in the POI file, but the two artworks continue to be absent from the file…. while there is maybe a technical reason to their absence, but definitely no „user oriented“ reason.

It would be great to find a solution in which not only the church, but also its two artworks, are created as three distinct POIs.

[ChristianK]

Hi Laurent,

There are uncountable artworks, even trees, benches, trashbins …….. in the OSM.
If I include all of these the database becomes useless if you search for something.
If you have 100 Artworks with no Name/Description this is useless and anoying for the User ..

So I remove a lot of POIs from the DB if there is no NAME= or DESCRIPTION= tagged.
So add a description (a real one 😉 ) or at least a name and these artworks will be shown in the POI-DB

Here is the ruleset (ONLY for POIs, not for map):

	<translation>
		<name>noname historic</name>
		<description>only viewpoints, peaks, volcanos, etc with name or description or url survive in POI</description>
		<match mode="and">
				<tag k="historic" v="castle|memorial|monument|ruins|wayside_cross|wayside_shrine|boundary_stone"/>
				<notag k="name|description" v=".*"/>
		</match>
		<output>
			<copy-all/>
			<tag k="historic" v="historic_noname"/>
		</output>
	</translation>


	<translation>
		<name>noname tourlsm</name>
		<description>only viewpoints, peaks, volcanos, etc with name or description or url survive in POI</description>
		<match mode="and">
				<tag k="tourism" v="viewpoint|attraction|artwork"/>
				<notag k="name|description" v=".*"/>
		</match>
		<output>
			<copy-all/>
			<tag k="tourism" v="tourism_noname"/>
		</output>
	</translation>
	
	<translation>
		<name>noname place</name>
		<description>only viewpoints, peaks, volcanos, etc with name or description or url survive in POI</description>
		<match mode="and">
				<tag k="place" v=".*"/>
				<notag k="name|description" v=".*"/>
		</match>
		<output>
			<copy-all/>
			<tag k="place" v="place_noname"/>
		</output>
	</translation>	
	
	<translation>
		<name>noname natural</name>
		<description>only viewpoints, peaks, volcanos, etc with name or description or url survive in POI</description>
		<match mode="and">
				<tag k="natural" v="peak|volcano"/>
				<notag k="name|description" v=".*"/>
		</match>
		<output>
			<copy-all/>
			<tag k="natural" v="natural_noname"/>
		</output>
	</translation>
	
	<!–translation>
		<name>noname amenity</name>
		<description>only viewpoints, peaks, volcanos, etc with name or description or url survive in POI</description>
		<match mode="and">
				<tag k="amenity" v="parking"/>
				<notag k="name|description|operator|access|ref" v=".*"/>
		</match>
		<output>
			<copy-all/>
			<tag k="amenity" v="skipped"/>
		</output>
	</translation–>	
	
	<translation>
		<name>noname leisure</name>
		<description>only viewpoints, peaks, volcanos, etc with name or description or url survive in POI</description>
		<match mode="and">
				<tag k="leisure" v="garden"/>
			<match mode="or">
				<notag k="name|description|operator|ref" v=".*"/>
				<tag k="garden:type" v="residential"/>
			</match>
		</match>
		<output>
			<copy-all/>
			<tag k="leisure" v="skipped"/>
		</output>
	</translation>	

1 Teilnehmer(n) gefällt dieser Beitrag

mbe57

[ChristianK]

Emux wrote:

Doesn’t this mean missing POI ?

No, If you splitt the pois in those 3 parts the nodes are cought in the first filter and remain.
The nodes of the way/pois that are deleted after you convert way2nodes are still in part one of the filterset.
Same with the rel/pois.

Absolute save….

Emux wrote:

We prefer any improvements to be done in the writer code,
so poi-writer can be used directly with Geofabrik downloads by all users,
without having to use other tools to modify the osm files.

Agree, however the art of making maps/pois out of OSM data IS preprozessing.
(At least since we have a tool that is as ingenious as your Mapsforge for creating those maps—I won’t forget that.)

So Thanks for all your work
Christian

[LaurentG]

ChristianK wrote:

So I remove a lot of POIs from the DB if there is no NAME= or DESCRIPTION= tagged.

I understand… and I agree.
Thank you for the explainful answer.

I’ll check, and if needed, I’ll add name and description for some of these artworks.

Best regards
Laurent

1 Teilnehmer(n) gefällt dieser Beitrag

ChristianK

[Juanjo]

your rules description states ‚only viewpoints, peaks, volcanos, etc with name or description or url survive in POI‚, however the rule is as following:

{<notag k="name|description" v=".*"/>}

So only artworks having either a name or description end up in the POI database.

I know several artworks which do not have neither name nor description tags but do have a ‚website‘ one. It would be fine to include those as well; in Oruxmaps, those links are clickable

[ChristianK]

It’s notag rule, so a and/not.
And if true it destroys the tag.
It’s working korrekt.

[Emux]

We also tested the Germany and France poi files on the Mapsforge server and they were created successfully.

So I set the „way-filtering“ option off by default in poi-writer:
https://github.com/mapsforge/mapsforge/pull/1773

---

Cruiser and Mapsforge developer

2 Teilnehmer(n) gefällt dieser Beitrag

ChristianK, LaurentG

[Autor]

Beiträge