Re: [OSM-dev] How can I force refresh of map tiles after move to a new backed?

[Mateusz Konieczny via dev]

Dec 29, 2020, 12:23 by t...@compton.nu:

> On 29/12/2020 10:04, Mateusz Konieczny via dev wrote:
>
>> In this case 12
>>
>> " when I zoom out to
>> https://www.openstreetmap.org/#map=12/52.20141/21.30912 
>> <https://www.openstreetmap.org/#map=19/52.20141/21.30912>
>> it shows as under construction "
>>
>
> The low zoom tiles, which is everything up to 12, are only
> rendered once a month.
>
Thanks! Sorry for confusion then, so this case is clearly
unrelated to infrastructure change.
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

[OSM-dev] Code for obtaining tag info from OSM Wiki infoboxes and from data items

[Mateusz Konieczny via dev]

If someone needs code for obtaining data from OSM Wiki about tags
(yes, taginfo is doing this already and for most uses it is enough)
and also needs info from data items then
https://github.com/matkoniecz/osm_wiki_tag_api
may be useful.

It has a Python script that obtains data from OSM Wiki infoboxes
and data items, compares them and finds where edits are needed.

Nothing groundbreaking, but finding proper way to do this
(without writing my own parser and without using recommended
but not working tools for extracting data item info).

More likely useful as inspiration and pointer toward useful libraries
than for direct use, but if someone is interested I can rewrite it
a bit and publish as a pip package.

Note: data items are not fully parsed into human readable form
(parsing tag lists such as "implies", "requires") as
(1) it is quite obnoxious to implement
(2) not really needed for my task
of finding where infobox templates are without parameters
and silently use data items.
(3) for complex fields such as seeAlso, requires etc it is
safe to assume that data item has the same data or of 
worse quality, so I wanted to just detect where it is
silently used
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Automatic generation of short_name / alt_name where missing and obvious

[Mateusz Konieczny via dev]

It is not a proposal for an automatic edit, it is intended as an opposite -
so I will be able to generate names locally and will have no need to add them 
to OSM database.


I am aware of 
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
and anyway that this thread would not be sufficient to cover this requirements


Nov 21, 2020, 17:02 by si...@poole.ch:

>
> By definition if you can generate it mechanically, you shouldn't  be 
> adding it to OSM.
>
> Am 21.11.2020 um 15:20 schrieb Mateusz      Konieczny via dev:
>
>> Is there some existing code/library/tool for generatingobvious 
>> short_name / alt_name from other tagged data?
>>
>>
>> I am implementing it right now for one of my programs  
>> and I would prefer help in existing project rather thanimplement yet 
>> another
>> version of the same.
>>
>> ___dev mailing list>> 
>> dev@openstreetmap.org>> https://lists.openstreetmap.org/listinfo/dev
>>

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

[OSM-dev] Automatic generation of short_name / alt_name where missing and obvious

[Mateusz Konieczny via dev]

Is there some existing code/library/tool for generating obvious 
short_name / alt_name from other tagged data?


I am implementing it right now for one of my programs  
and I would prefer help in existing project rather than implement yet another
version of the same.
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Standardized feature/tag database idea & proposal

[Mateusz Konieczny via dev]

Nov 16, 2020, 10:21 by si...@poole.ch:

>
> the iD presets  are the law of the land and anything else is simply 
> irrelevant.
>
>
That is so overstating things that it ceases to be an useful statement.

iD presets and 
"press button here to `upgrade tags`  without explanation what and why and how 
actually happens"
are powerful, but it is only a part of what influences tagging.
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] dev Digest, Vol 188, Issue 1

[Mateusz Konieczny via dev]

(0) if you want to reply it would be better to disable digest mode

Nov 16, 2020, 01:21 by jayands...@gmail.com:

> Oh wow. So Data Items basically is what I'm proposing. I also didn't know it 
> also had a role in the Wikibase Registry (probably wouldn't want to get rid 
> of that).
>
> I guess my only issues with the current system would be:
> 1. Lack of quality control (it said in the Wiki page for Data items that it 
> has not been implemented yet). Quality control should probably apply to the 
> corresponding Wiki pages themselves too.
>
Wiki pages are relatively well watched (warning: I am biased here,
as I am one of people quite active in that field).

Data items are not, as watchlisting them is dysfunctional (no way to skip
translations that given person cannot review, no way of grouping edits, 
standard edit
leave no description of edit and so on)

> 2. Lack of synchronization between the Data items and their Wiki pages.
>
This sort of works and is causing issues due to lack of control in Data Items

> 3. JOSM doesn't use Data items yet. 
>
I am dubious is it useful or going to happen, but it is up to JOSM developers

> 4. The MediaWiki interface is still hard for new users to grasp.
>
And note, that even if data items interface would be very easy - you still need
wiki pages for freeform description/comments

> 5. Layouts for Wiki pages aren't standardized. Something else my proposal 
> could address would be the conversion of Proposed Feature pages to actual 
> Wiki pages (would require a standardization) but honestly it is not the most 
> important thing.
> 6. Devs still have to manually add presets. One of my first issues on the iD 
> repo was actually concerning this (btw uneducated at how approved features 
> worked at the time): > https://github.com/openstreetmap/iD/issues/7552>  
>
I am dubious whatever authors of editors would abandon maintaining presets and 
switch to
simply pulling from Data Items

Note that, for example, JOSM and iD are using icons in different styles.


___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Standardized feature/tag database idea & proposal

[Mateusz Konieczny via dev]

Nov 15, 2020, 19:14 by jayands...@gmail.com:

> Idea
> Has anyone ever thought of creating an official database that stores all of 
> the approved and in-use tags/features in OSM? 
>
Yes. 

Depending on what one means by "database" OSM Wiki can be considered as one.

Wikidata copy ( https://wiki.openstreetmap.org/wiki/Data_items ) is definitely 
one.
How your proposal differs from data items?

>
> Reasoning
> This could allow the editors (iD and JOSM, StreetComplete, GoMap!) and data 
> consumers (osm-carto,. Mapbox etc.), to easily stay up-to-date with new 
> features, without requiring their developers to browse the Wiki etc.
>
I see no benefit whatsoever of data items (from perspective of someone involved 
in making 
StreetComplete and was active in osm-carto development).

Browsing Wiki, Taginfo, reviewing how tags are actually used and so on would be 
definitely needed.

>
> Examples
> Both iD and JOSM have their own preset file/repo and are independent of each 
> other. Creating a database that could be used as a dependency of both that 
> would store these feature presets and their fields means:
>  - Both are up-to-date and in-sync
>  - Adding new presets could be done automatically by retrieving and parsing 
> data from the DB. 
>
There is a good reason why presets are created manually and not pulled from 
unreviewed
dataset (note that JOSM and iD have separate presets despite that pulling from 
another preset
would be technically possinle)

> Creating applications that use OSM data can be hard and time-lengthened by 
> requiring developers to browse the Wiki to find all of the features and their 
> keys and values. Having a database that they could easily get the keys they 
> want, their values, etc. would > significantly>  allow greater OSM developer 
> potential.
>
I am unsure what would be difference.

> Specifics
> The specifics as to how this database would be arranged such as to where 
> presets/fields/tags/features go has not been thought of yet. I just wanted to 
> ask if this has ever been proposed before. If someone would like me to make a 
> DB layout to help them better understand what I'm proposing, I'd be happy to 
> do so. 
>
> My pre-DB construction proposal 
>
> Before any type of database is made, one would would > construct a dedicated 
> page structure on > openstreetmap.org >  > that 
> would display and be in-sync with all of the Features from the DB in a format 
> similar to the Wiki, and then > remove all of the features from the Wiki 
> altogether.
>
> Why?>  If you see in > Compiling and distributing the DB>  below, a Wiki bot 
> is going to be required to get all of the pages for all of the 
> already-standard features. Most of the features' pages do have a similar 
> structure as to how they are arranged (template that shows what elements they 
> use, Keys' values and their descriptions are stored in a table, etc.), 
> however these pages would be > impossible>  to parse thoroughly with a 
> computer and are going to require team of humans to get all of their data. 
>
> New features that are proposed and approved after the database would be 
> created would require them to be hand-added. Making a standard way to propose 
> and approve new features on a new part of the website with formatting 
> constraints and database-syncing abilities that MediaWiki cannot offer, would 
> mean that the DB would never have to be physically touched again and ensure 
> greater long-term DB management efficiency.
>
> So why basically delete one of the primary functions of the Wiki and create a 
> new system on > openstreetmap.org > ?
> I recently have got into the OSM community head-on in the past two months. I 
> have never really contributed to Wikipedia or any other site that uses the 
> MediaWiki website format so learning about how to contribute and get around 
> the OSM Wiki took time (learning about the proposal process, Templates, talk 
> pages, formatting, the list goes on and on...). It also made me realize that 
> this could discourage new users from ever looking into the depths of OSM or 
> even finding the Wiki at all. The WikiMedia interface is not the prettiest 
> either. It can take time for new users to explore and find what they are 
> looking for.
> (Also, this would mean moving the proposal process over to > osm.org 
> >  too)
>
> Therefore, I think creating a easily accessible, pretty, and 
> easily-contributable interface on > osm.org >  would 
> strengthen the OSM community significantly. For example, a heading called 
> "Features" could be added to the left "GPS traces". It would greet the user 
> with the primary features of OSM (kind of like the "Map features" on the Wiki 
> already does) and Feature pages would have a standard format that is 
> consistent throughout the website (unlike Wiki pages where tables for values 
> can be different, proposals can be different, etc.). 

Re: [OSM-dev] Comparing quality of different geocoders?

[Mateusz Konieczny via dev]

Aug 26, 2020, 11:04 by lon...@denofr.de:

> Hi,
>
> On Wed, Aug 26, 2020 at 09:11:44AM +0200, Mateusz Konieczny via dev wrote:
>
>> Is anyone aware about some test suite comparing different geocoders?
>>
>> Something with query + expected result pairs, and listing where Nominatim / 
>> Photon / etc succeeded/failed?
>>
>> I want something like that, tried to find one and failed.
>>
>> I want to ask whatever I missed something like that before I will make it.
>>
>
> There are a couple of test suits out there. The two that come
> immediately to mind are:
> https://github.com/geocoders/geocoder-tester
> https://github.com/pelias/fuzzy-tester
>
Thanks!

I will need to look how tightly pelias/fuzzy-tester is
integrated with just pelias and is it viable to expand/use
it to support testing REST apis.

Maybe it will be easier to write something small from scratch.

> The issue with all these is that you have to define what you
> actually want to compare. Depending on what kind of queries you
> run and how you define the results you get, you'll get very different
> results.
>
Oh, I know!

For example cases such as "Elementary school number 12, Streetname 19"
where address and object are at different locations and expected result
completely depends on what user wants.

Or slang/local/vulgar names where some would prefer not finding them
and not listing them over finding them, even if naming is real.
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Questions on modifying openstreetmap-carto

[Mateusz Konieczny via dev]

"reading from relation" part is quite hard.
I have no idea how to do that.


Aug 26, 2020, 09:50 by mapper+...@minoa.li:

> Hello again,
>
> I am starting to get the basics of adding new fields to project.mml, but I 
> now wish to update “amenity-points” so that bus stops use the network name 
> from the “stop_area”, like they do in France. At the moment I can manage:
>
>  tags->'network' AS network,
>
> … which calls up the network tag from the node only. How do I make it to read 
> from the “stop_area” relation too?
>
> Apologies for being very specific: I am very new to anything beyond simple 
> recolours.
>
> — ika-chan!
>
>> On 25 Aug 2020, at 21:44, Andy Townsend  wrote:
>>
>> On 25/08/2020 19:52, Mateusz Konieczny via dev wrote:
>>
>>> Yes, I always used normal text editor.
>>>
>> Same here.  There are projects such as 
>> https://wiki.openstreetmap.org/wiki/TileMill which were / are designed to 
>> automate map reloading after changes, but when I last used TileMill (a long 
>> time ago) there were signnificant problems using TileMill with an OSM 
>> Carto-derived style (not least - there are so many tabs that they 
>> disappeared off the screen).  I tend to just reload when I want to rerender. 
>>  When changing my own OSM Carto-derived map style I use 
>> https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/update_render.sh
>>  and 
>> https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/update_carto.sh
>>  to reload data (the first if a lua script has changed and the database 
>> needs to be reloaded; the second if only a style file has changed and the 
>> style just needs to be recompiled).
>>
>>
>>> If you want to see how changes are done
>>> I would recommend looking at pull requests
>>> and commit history.
>>>
>> I tried to summarise "Adding a change to OSM Carto" at 
>> https://www.openstreetmap.org/user/SomeoneElse/diary/43041 ; some of that 
>> won't be relevant but some of it might still be - things like testing the 
>> effect of a colour change.
>>
>> If you haven't seen it already, please do read 
>> https://ircama.github.io/osm-carto-tutorials/git-workflow/ and the related 
>> tutorials there - they're excellent!
>>
>> Best Regards,
>>
>> Andy
>>
>>
>>
>> ___
>> dev mailing list
>> dev@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/dev
>>
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
>

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

[OSM-dev] Comparing quality of different geocoders?

[Mateusz Konieczny via dev]

Is anyone aware about some test suite comparing different geocoders?

Something with query + expected result pairs, and listing where Nominatim / 
Photon / etc succeeded/failed?

I want something like that, tried to find one and failed.

I want to ask whatever I missed something like that before I will make it.
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Questions on modifying openstreetmap-carto

[Mateusz Konieczny via dev]

Yes, I always used normal text editor.

If you want to see how changes are done
I would recommend looking at pull requests
and commit history.

25 Aug 2020, 18:53 by mapper+...@minoa.li:

> Hello,
>
> I have made significant progress in creating a tutorial for a fantasy map 
> server on the wiki, having gone as far as getting Nominatim and its UI 
> working last night.
>
> Now, I am moving my focus to modding OpenStreetMap Carto, and I know a few 
> very basic modifications, like recolouring existing features (see 
> https://wiki.openstreetmap.org/wiki/User:Ika-chan!/British_road_colours). 
> However, I would like to expand on mere recolouring and ask how I can modify 
> OpenStreetMap Carto to:
>
> 1. Render “railway=rail” in a different colour when “highspeed=yes”.
> 2. Render “railway=station” in a different icon when the key “network” 
> contains a certain value or a combination of certain values like (but not 
> exclusively) “National Rail” or “TfL Rail”.
>
> I am still new to OpenStreetMap Carto’s language: I assume that the 
> developers use a text editor for all the rendering rules?
>
> Best,
>
> — ika-chan!
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
>___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] OAuth difficulties from node.js client

[Mateusz Konieczny via dev]

Osm website had sone downtime,
maybe your code is ok?

16 Jul 2020, 17:04 by nick.whitel...@solent.ac.uk:

> Hello everyone,
>
> Realise this might be a difficult one, but posting it here in case anyone's 
> encountered similar problems or if anyone can obviously see what's wrong with 
> the request (see below).
>
> I'm trying to connect to the OSM OAuth API request_token endpoint from a 
> node.js based client.
>
> If I use the recommended example on the wiki for node.js, it works correctly 
> (I get a token and a secret back), _however_ the 'request' module is now 
> deprecated so probably not the best thing to use, even though it handles 
> oauth automatically.
>
> I found an alternative module which generates the correct parameters to send 
> to the request token endpoint at:
>
> https://www.npmjs.com/package/oauth-1.0a
>
> and it generated parameters which look vaguely sensible:
>
> { oauth_consumer_key: 'EcdM735JygrmO42fzw8SIfbFUMDy1ShVY5bBnefn',
>  >  >   oauth_nonce: 'cNvPEgdgjvQWX5FgS56XkyLaMhQNggmh',
>   oauth_signature_method: 'HMAC-SHA1',
>   oauth_timestamp: 1594910535,
>   oauth_version: '1.0',
>   oauth_callback: 'http://localhost/app/',
>   oauth_signature: 'WuYA7G8s4qPCht+cF7t7FpTP0ck=' }
>
>
> However if I send that to the request_token endpoint (using node-fetch) I get 
> a 500 error.
>
> Fiurthermore, if I use curl to send the same data to the endpoint, I also get 
> a 500:
>
> curl --data 
> "oauth_consumer_key=EcdM735JygrmO42fzw8SIfbFUMDy1ShVY5bBnefn_nonce=cNvPEgdgjvQWX5FgS56XkyLaMhQNggmh_signature_method=HMAC-SHA1_timestamp=1594910535_version=1.0_callback=http%3A%2F%2Flocalhost%2Fapp%2F_signature=WuYA7G8s4qPCht%2BcF7t7FpTP0ck%3D"
>  > https://www.openstreetmap.org/oauth/request_token
>
> I'm guessing something's wrong with the signing process. I used the examples 
> given in the oauth-1.0a documentation to generate the parameters.
>
> I'm surprised I'm getting a 500 rather than say a 400.
>
>
> Thanks,
> Nick
>
>
>
>___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] OpenStreetMap Cartographic: A client-side rendered OpenStreetMap Carto

[Mateusz Konieczny via dev]

I just wanted to thank you for
working on this.

(Sadly I have no useful comments,
hopefully such message is ok)

11 Jun 2020, 05:32 by dev@openstreetmap.org:

> I've been busy with
>
> On 2020-05-24 10:26 p.m., Joseph Eisenberg wrote:
>
>> Thank you for making this, it looks like a lot of work!
>>
>> These client-side vector tiles at z8? 
>> (https://pnorman.dev.openstreetmap.org/cartographic/mapbox-gl.html)
>>
>> My laptop (2015 Macbook Pro, 16 GB RAM, 2.2 GHz Intel Core i7) appears to 
>> use some effort to show areas with a large amount of data,
>> For example if I view England + Wales on z8 and then move over to the 
>> Netherlands and then to Germany, at z7 and z8,
>> CPU usage goes up to >100% for a time, and there is a noticeable delay. 
>> Perhaps part of this is a delay in serving the tiles?
>>
>
> I turned on Content-Encoding based compression which cuts the bytes 
> transferred in half. This helps significantly.
>
> In general vector tiles have more large tiles, even if the average tile size 
> is the same. The largest z8 tile in the area is 1MB transfer size while an 
> average weighted by requests on the tile.osm.org level 2 cache is 189k 
> uncompressed. For comparison, four z9 raster tiles from tile.osm.org are 
> about 200kb, a fifth of the bytes transferred. Retina tiles would decrease 
> the size different.
>
>
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
>___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] All possible fields of an address object in Open Street Map

[Mateusz Konieczny via dev]

https://wiki.openstreetmap.org/wiki/Addresses may be helpful, it is an attempt 
to
document how addresses are tagged in OSM


> is OSM (Nominatim) using OpenCageData address-formatting ?"

Depends on what you mean by that. Nominatim is extracting geocoding info
from OSM (and it may or may not use OpenCageData address-formatting)

OSM (database edited by mappers) is not using OpenCageData format
but its own tagging system documented in 
https://wiki.openstreetmap.org/wiki/Addresses

BTW, if https://wiki.openstreetmap.org/wiki/Addresses will be confusing or 
unclear please comment
at 
https://wiki.openstreetmap.org/w/index.php?title=Talk:Addresses=edit=new
and there is decent chance that documentation will be improved

May 11, 2020, 15:06 by pascal.gir...@insa-lyon.fr:

> Good morning,
>  
>  I apologize in advance if this is the incorrect contact channel formy 
> question.
>  I posted it on OSM help forum in April and I had no answer.
>  
>
> I am developping a web application and I use Nominatin service to  get 
> addresses.
>
>
> In JSON format, Nominatin sends an address object like this :  "address": 
> {"road": "Hillcrest Road", "suburb": "Gidea Park",  "city": "London 
> Borough of Havering", "state_district": "Grand  Londres","state": 
> "Angleterre", "postcode": "RM11 1EA", "country":  "Royaume-Uni", 
> "country_code": "gb"}. Of course, address fields  change depending on the 
> country.
>
>
> In the database of our web application, we would like to build a  table 
> to store all fields of an address object of OSM, because we  want to be 
> compatible to all addresses around the world. I've been  looking for 
> days, for the list of all fields contained in an  address object of OSM : 
> on the net, in documentations, in  nominatim and osm2pgsql code.
>
>
> I saw this post on Open Street Map Help : > 
> "https://help.openstreetmap.org/questions/61683/all-possible-fields-of-address-object;
>  
> >
>  .
>
>
> But :
>
> 1) it was in January 2018,
> 2) the answer was > 
> "https://github.com/OpenCageData/address-formatting/blob/master/conf/components.yaml;
>  
> 
> 3) and > 
> "https://github.com/openstreetmap/Nominatim/blob/6c1977b448e8b195bf96b6144674ffe0527e79de/lib/lib.php#L63;
>  
> 
>
> The > "https://github.com/osm-search/Nominatim/blob/v3.4.1/lib/lib.php; 
> >  is 
> different than witch I quoted above in point 3).
>
>
> Concerning the above point 2) :
>
> is OSM (Nominatim) using OpenCageData address-formatting ?
> Can I rely on it to build my address table ?
>
> Please help me...
>
>
> Many thanks in advance for your response.
>
>
>
>
> Pascal Girard
>

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev