Upon getting the news of being awarded a scholarship to attend and participate in the State of the Map Tanzania 2023, I was so excited to travel since it was my first time to visit Tanzania. I thank God that I made it to the conference which commenced on the 20th-23rd of January.

My highlights from the first day were from the Resilience Academy I was amazed by the tremendous work they do to impact the society through collaboration and partnerships to train young people with skills and knowledge to achieve the country’s sustainable development goals. My evening was sparked when I toured around the neighborhood I noticed that the transport system was properly planned with easy access and convenience.

The lightning talks were very insightful as people shared their experiences in OpenStreetMap and how they have been able to grow their communities. I realized that Tanzania has a wide network of mappers whereby they have established and promoted youth mapping chapters within their universities as compared to my country therefore I learned that more effort to grow our community here in Uganda is key in order to achieve the designed goals for the country with the use of OpenStreetMap.

I got a chance to participate in the Advanced QGIS training with the trainers Ian Coady and Steve Penson who did an amazing job teaching us the course exhaustively. I learnt a lot and I plan to use the knowledge to advance in my career. I was also given an opportunity to present the application of photomapping in OpenStreetMap with the use of Mapillary. https://youtu.be/OgoRLDUNhHQ

Meeting the Geochicas (women in Geospatial) was enlightening, we got to share experiences and the way forward to expand the number of women in this sector. The conference gathered many people from different parts of the world. Interacting and engaging with them broadened my thinking scope from their experiences in OpenStreetMap and beyond. I made so many friends and am grateful for having them join my network.

I would like to thank the organizers of the conference OpenMap Development Tanzania for giving me the scholarship to be part of the many great minds in OpenStreetMap and my people in Uganda for their overwhelming support.

Photos; https://drive.google.com/drive/u/0/folders/1chBIB4oVMl85f1zsdms-AulbWWa5VY-0

Unknown login

I am looking for a way of making an API call and obtain a list of routes that started within a given location and ended within a given location:

Inputs or columns from data table

Input variable the departure place: Lat range and Long range Input variable for arrival place: Lat range and Long range Input variable (range) for the duration of the trip Filtering per vehicle type, avoid certain routes per multiple variables….. Timespan for the search (data start and date end).

Output:

List of all the trips existing for the above, including :

date and times polyline format if possible Name of roads, turn left/right Speeds on the streets (optional)

Does anyone know if at all possible?

In diesem Blogpost zeige ich ein Python Skript mit dem osm2pgsql Importe automatisiert werden können. https://jakobmiksch.eu/post/osm2pgsql-replication-script/

In this blog post I show a Python script how to automate osm2pgsql imports: https://jakobmiksch.eu/post/osm2pgsql-replication-script/

Recently I found Streamlit which is a pretty cool Python library that makes it easy to create web apps for visualising data.

I converted changeset dump from planet.osm.org to Parquet file format and uploaded it to AWS S3 storage. Then created this streamlit app in their free cloud: https://ttomasz-tt-osm-changeset-analyzer-main-apdkpy.streamlit.app/ which displays some basic statistics.

The app leverages the power of DuckDB, a database engine that can query these files over internet on demand. Parquet files, which are a popular format in modern cloud data lakes, have several advantages over traditional file formats. They are column-oriented, compressed, and support range requests, which means that you can download only the portion of the file you need, instead of having to go through the entire file, making processing larger datasets much faster.

DuckDB works similarly to SQLite in that it doesn’t have a dedicated server. You run the queries locally [0]. This makes the setup super simple you either install the binary or configure connection in IDE like DBeaver and you can run SQL queries.

Running these simple SQL queries over remote Parquet files takes about a minute or two. Trying to do the same with a custom script on raw changesets.xml.bz2 file would run longer not to mention that the effort to prepare the code would be much much larger.

It would be great if OSM hosted more “consumption ready” data instead of relying on users to do their own coding and parsing.

Let me know if you have some ideas for charts/tables that could be added to the demo.

[0] - well in this case they are running on streamlit cloud’s server but you can run the queries locally on the same parquet files easily

O actual cruceiro da Alfarrapa é contemporáneo do situado no cruce de Refexón co Tabolado. O seu autor foi don Juan Míguez Domínguez. Anterior a eles é o do barrio da Torre. Os tres compóñense de pedestal, fuste octogonal e cruz. Non teñen imaxes.

O anterior cruceiro que aquí estaba caeu por mor dun carro que chocou con el, segundo unha versión. O párroco, don Esteban Viso, decidíu poñer os restos no muro da súa viña, ben visibles, e restauralo. Nunca pasou tal. Levantouse un novo cruceiro, por obra e desexo de don Juan Míguez (mesmo autor que o do Tabolado). Os restos están ben visibles no muro da antiga viña de don Esteban, no Pireiro, enfronte dun cruce de camiños, así que poden visitarse e fotografar con toda facilidade.

Large waterways such as rivers and canals are important features on small scale maps. This is the fourth problem I wanted to work on described in this blog post.

(This post is part of a series about generalization of OSM data.)

What features and properties to use?

Rivers are mapped as linestrings and wider rivers also as polygons. As base of our processing we can’t just use the polygons, because they don’t exist everywhere. And we do need a linestring in the end. A river is not just a bunch of polygons that might or might not touch at some place, a river is a linear thing that should always be connected through its whole course.

For many rivers there are relations tagged type=waterway that collect all ways that make up a river. That sounds interesting, especially because the members can have roles main_stream and side_stream which makes it easy to just follow the main stream and discard the rest.

But there are also some problems with those river relations. First, not every river has one. So we still need some code to handle those rivers which don’t have this. Second, large relations in OSM tend to be brittle. They are easy to break accidentally when editing. So we need some code to check whether there are problems and fall back to a different solution when, say, a piece of the river is missing. With the waterway lines and polygons this is less of a problem, because breakages are easier to spot on the map and easier to fix so they tend to be okay.

An additional problem is that it isn’t always clear what a waterway relation is supposed to model. The Rhine river for instance splits up into several branches after entering the Netherlands at which point it gets several names. The Rhein relation (note the German name of the river on the relation) contains some of these branches (for instance the Waal, but not the smaller IJssel). These inconsistencies make it hard to figure out how to use those relations properly. I still think they can be used as part of the solution, for instance with helping to differentiate between main and side channels, but I leave that for the future.

So we are going primarily with the ways tagged as waterway and also use additional data as needed and where available. We are only looking at waterways tagged as river or canal. Streams, ditches etc. are too small to matter for our use case here. The canals are needed because some rivers have been canalized and are tagged as such but we still want to render them.

Selecting large rivers

Before we can do anything else, we have to decide on some criteria for selecting the rivers we want to show. The amount of water flowing down the waterway on average is probably a good measure, but we don’t have that information. What we do have, at least for some rivers, is the width of the waterway. Rivers might have different depths and flow speeds, so width isn’t the same as the amount of water, but its close enough, and arguably even more important, because a wider river certainly looks more important than a narrow one.

Unfortunately only about 2% of ways tagged as waterway=river have a width tag. But we have something else: Lots of rivers, especially the large ones, are not only mapped as a linestring but also as a polygon. We can figure out how wide those polygons are and then add that width to the ways which don’t have one. This process doesn’t have to be perfect, we will simplify those linestrings later anyway, it just has to be good enough to give us a rough approximation how wide a stretch of the river is so that we can decide whether this river should make it onto the map.

It took some experimenting, but I found a way to do just that. For every waterway polygon we use the PostGIS ST_MaximumInscribedCircle() function to calculate the “width” of that polygon. Then we can find all waterways intersecting the polygon and add the width to those ways. The details are a bit more complex, but it works reasonably well for most of the cases I tested. (The code will be available together with the other stuff I am describing here soon.)

Building the river network

What we have now are lots of ways, some of which have an additional width property. Those that don’t are smaller rivers that didn’t have a width tag to begin with and are not mapped as polygon. But that’s okay, because we don’t want to render those small rivers on low zoom levels anyway.

But we still need to create longer, complete linestrings from the pieces we have. A river can sometimes be wider and then become narrow again. We don’t want the wider pieces to show up on the map and the more narrow ones hidden.

To fix this we need to build the network of all the rivers. First we split up all way geometries into segments (each connecting two points). Then we re-assemble those segments into pieces going from one branching point to the next creating a directed graph. Each edge in that graph gets the largest width property of all its segments. Then we walk through that graph downstream, each edge gets as width either the width it had before or the upstream width, if that was larger. So this way a river only ever gets wider, never narrower. If we draw all rivers wider than a certain value, we always have a continuous line from the place where it first was wider than that minimum value down to the sea.

Creating this graph and working with it is rather difficult to do in SQL and quite expensive. Instead we just read all the data from the database and do the processing in C++. Using reasonably efficient data structures and algorithms this runs in a few minutes for the whole of Europe and needs only a few GB of memory. (There are probably ways to make this even more efficient, but its good enough for now.) After processing the data is simply stored in the database again in an extra table.

There are some problems with this algorithm. A river can split into several branches which, in this case, will all get the same width property. If they join up again after a short stretch this doesn’t matter much. But if they diverge and run into the sea in different places, you’ll not get the right result, for instance in the already mentioned case of the Rhine splitting into Waal/Nederrijn/Lek/IJssel. The Po river in northern Italy is another case where this doesn’t work so well due to the extensive canal network there.

You can see the result in this image. All rivers and canals are in blue and the assembled rivers wider than 200m in red. Click on the image to get a large version.

Conclusions

I have glossed over a lot of detail here and there are still many problems. This is far from a complete solution, but I would classify the current state as “promising”. I probably have to remove rivers that are shorter than some value. This happens most often for small rivers that nevertheless have a wide mouth where they flow into the sea. And I still have to actually do the simplification of the linestrings themselves and sort out the name labelling.

What’s interesting about the solution I am using here is that it contains a part which uses the strength of the PostgreSQL/PostGIS database (merging the linestring and polygon data to get the width onto the linestrings) with a part that uses the strength of a C++ program (assembling the network and propagating the width property downstream). Had I only one tool at my disposal this would have been much harder to do. And the code building the river network can hopefully be also used for other network-type data such as road or railway networks.

Planet Lite, our copyright-free map of the entire world, has been upgraded with enhanced features and issue fixes have been made to our lite version of MapTiler Planet. This latest release of the Lite version of MapTiler Planet has improved compatibility, boundaries, and some new features and upgrades.

Switch between copyright-free and highly detailed maps

The Planet Lite v1.1 schema is now compatible with the MapTiler Planet v3.14 schema. There are some compromises due to the different maximum zoom levels (10 compared to 15 for MapTiler Planet) and differing quantities of information. However, any features you have styled for Planet Lite data are transferable to MapTiler Planet, and the same is possible in reverse. This allows you to keep the familiar look of your maps for your users, no matter which dataset you are using, e.g.:

• Mountain peak elevations in feet in the USA.
• Boundaries with country labels on either side at all zoom levels.
• Lakes labels that follow along a center line.
• Utilizing attributes in the transportation layer to style the whole network.

Remember you can choose Planet Lite as the data source using the customize tools in MapTiler Cloud. The advanced editor can be used to create beautiful cartography too:

Get Started

Improved Boundaries

There was a massive enhancement in the boundary layer where you can now use Customize tools to highlight the specific view of disputed boundaries. There are also now unified naming for disputed borders, so you can apply your own style consistently.

Also, the USA now includes boundaries for counties that align perfectly with the level 2 boundaries in our Countries tileset.

Map Data upgrades

We’ve made many other improvements to Planet Lite, such as adding more Wikidata and GeoNames IDs to place names. This allows you to connect to other datasets that use the same codes.

Highways in the USA now appear from zoom level 4, so you can show higher-level transit maps. There are also new features, such as extra rivers and lakes in Australia.

The highway shields in the USA have also been enhanced to show more precise information.

You can find out more about Planet Lite or start using it straight away:

GET STARTED

Self-hosting? You can download Planet Lite here.

For this area beside the Blue Ridge Wilderness, I started out by adding what I knew of the Dangerous Park Trail and the Pueblo Park Interpretive Trail. There were a few miles of Dangerous Park already on the map, but they didn’t get all the way to the park. Unfortunately, the trail was diverging from what the Forest Service claims at the point I left it, so the little bit to the northern terminus includes guesswork. There’s some trail visible there.

I then worked on stuff in the wilderness and primitive area near the state line. It looks like someone has added in the trails from FS information (including attribution) in this area. I had a couple of adjustments based on my GPS, but the trail routes look good. I’m not sure if these are downloaded tracks or copied from the FSTopo. I’m seeing some changes between the two. The tracks that can be downloaded are more recent. I added signs to the mix. Guideposts and an information board. And parking.

I wanted to add the trails that connect to Dangerous Park, so I took the time to figure out downloading FS trail data again. There’s only about 4 different ways. Do they all connect to the same database or is it possible does one have to choose the right one to get the most recent data? All kinds of regulations are encoded into the tags on these trails. There’s also an indication of the state of the trail in “trail class”. Class 1 and 2 are generally represented here. Class 1 is minimally maintained and tread is intermittent and indistinct. Class 2 expects tread to be continuous, but still rough. Class 3 is continuous and obvious tread. These are trail_visibility statements! Always good to have that included.

So I got those trails added and while I was at it, I adjusted a few roads onto their route and added names and numbers. Lots of roads were called Saddle Mountain that are actually something else including a main one that is the Frisco Divide Road.

I also noticed that while someone added the bit of Dangerous Park I increased, they also added a line for WS Mountain, which heads south from the same area. I’m not sure why they did this as there was already a longer line for it already existing.

As I poke around the area to write this entry, I’m also seeing other things that need done. I didn’t add the information board that is by that trail or the little bit of road for parking at the trailhead and now I’ve seen a missing trail on the wilderness side. Oh dear.

Those not withstanding, I may be done with these edits. The earlier excursions were in Chiricahua, which has been mapped exceptionally well including trail visibility, SAC difficulty, trails are really on route, guideposts are there. Well, that’s what I remember from hiking it before, anyway. Maybe I should still check it? There were excursions along the CDT south of Lordsburg and the trail definitely isn’t perfect there, but I have limited feelings about the value of improving it. My personal improvements would be to move it so it climbs a thing once in a while instead of plodding along service roads for cattle water. It’s so much better when one gets high up. But that’s something to tell the folks who decide on the route and if they agree, then map it. There were excursions that were off trail. Nothing to map there.

MapComplete has - for some thematic maps - the ability to leave a review on an entity with Mangrove.Reviews. Up till now, I had no idea how much this feature was used. However, due to technical reasons I had another look to the reviews module and discovered the ‘download all’-option on mangrove.reviews

Mangrove Clients

The analysis was made with data from 20 january 2023, downloaded around 17:00 UTC time.

This data contained 660 reviews. As the website making the review is recorded, we can make a breakdown of the top websites:

• https://mangrove.reviews is unsuprisingly the most popular website to make reviews on, with 318 reviews made
• MapComplete is the second (and the biggest ‘external’ website), with 192 reviews (of which 13 are made with the development version)
• toggenburg.swiss is third, with 35 reviews

A variety of smaller websites follows, each with a few reviews made. At first glance, most of them seem to be swiss or german. Furthermore, there are 5 reviews made by localhost:1234 and 7 by localhost:5000. The former is probably me, testing the creation of reviews while developing.

The full table is listed below.

Themes

It seems that pet owners gave reviews the most. The ‘pets’-theme - first known as the ‘dog’ theme - yielded 35 reviews in total (if summed). The ‘Pin je Punt’-campagin by Visit Flanders (which included pubs and cafés) is a close second with 29 reviews, followed by the shops theme.

While it might be surprising that the pets-theme has such a high number of reviews, the reason for this is straight-forward: the review-module is placed on top of the infobox for vets, whereas most other layers do have the images module there.

Language

At last, due to the full client URL being saved, we also know what language the user interface was in when the review was made:

Locations

And as map makers, a quick geolocation-analysis can’t miss as well.

Unsurprisingly, most of the reviews are in Europe:

When zooming in, a clear cluster in Switzerland and Flanders is visible:

When keeping only the Reviews made with MapComplete, the cluster in Flanders remains:

(Copyright: pins are Mangrove Reviews, background map is OpenStreetMap of course)

Conclusions

So, no big conclusions and surprises in this little analysis. The reviews are being used - but not very much, especially in comparison with the image-upload feature. Placing the reviews higher up might help or including in into the questions flow. The core question is how important reviews are within the vision of MapComplete.

As usual, data is available online here, script is here

17/01/2023-23/01/2023

Mapping

• User bradrh consulted the US Forest Service Motor Use Maps to update motor vehicle access restrictions on forest roads and trails in several national forests.
• Bryce Cogswell (bryceco) listed every OpenStreetMapper that has managed to map for more than a thousand days without a break.
• Lejun described ► how to merge data from different sources into OpenStreetMap. He explained the different tools and methods, including the JOSM plugin UtilsPlugin2.
• Christoph Hormann wrote a blog post describing the problems with the name key and promised to try to propose a possible solution in his next post.
• Tomas_J has provided ►
  pictures and suggested tagging for a few Slovak-specific features.
• Valerie Norton (valhikes) has summarised her mapping activity around Gunnison, Colorado between February and September 2022. Details of each hike, with lots of photos, are posted on her blog.
• Voting on the suggestion to announce proposals on the OSM Community forum, as well as the tagging mailing list, has closed. It was approved with 48 votes for, 5 votes against and 0 abstentions.

Community

• OpenStreetMap recently hit a milestone with more than 10 million user accounts. The milestone was discussed on r/openstreetmap. It should be noted that only about 1.9 million of these accounts have been used to make a map edit.
• Daniel Capilla (dcapillae) has created ► a tutorial on how to make a metrominuto (a schematic map of a municipality or city that represents the distances between its main points and the average time it takes to walk between them) of your area of interest.
• Mevesscarto gave ► us an update on their progress to armchair map the French department Côtes d’Armor.
• watmildon explained the JOSM and MapWithAI workflow that they are using to add missing street addresses to OSM.

OpenStreetMap Foundation

• Get to know the new OSMF Board. In December 2022, four new members were elected to the OpenStreetMap Foundation Board, complementing the three members already serving. The new members, Arnalie Vicario, Craig Allan, Mateusz Konieczny, and Sarah Hoffmann, have joined Guillaume Rischard, Mikel Maron, and Roland Olbricht.

Local chapter news

• Nominations for the OpenStreetMap US 2023 Board Elections are now open. The OSM US blog has more details if you are interested.

Education

• UN Mappers has launched the UN Maps Learning Hub, a self-learning platform accessible to anyone interested in the OpenStreetMap project. Courses will be available in several languages and will cover aspects of topographic and humanitarian mapping. The OSM Basics course is already available.

OSM research

• With the release of the OSHDB (OpenStreetMap History Database) Version 1 for spatio-temporal analysis, the HeiGIT team at Heidelberg University has reached an important milestone. The data is open to everyone, whether they belong to journalism, science or humanitarian organisations. The ohsome dashboard allows you to analyse OSM temporal data for any region. A significant enhancement is the new OSHDB filters that allow practitioners to filter entities by the shape of the geometry (one measure of quality often discussed by the OSM community).
• GeoObserver has published ► the third part of its ‘Meierloch’ trilogy on the distribution of surnames and their visualisation on a map.

switch2OSM

• Roberto Brazzelli described ► how the municipality of Limone (Piemonte, Italy) provides a map of amenities using uMap. Data is maintained in OSM by council staff, but updates are quality controlled via QGIS with data cached in Google Sheets from Overpass queries.

Software

• Kshitij Raj Sharma has created ‘OpenStreetMap Stats Generator’, which uses osmium to analyse the change files from OSM and generate statistics in different file formats such as csv, json, and jpg. Results are also being tweeted. A second bot follows the recent trends on OSM and retweets the findings with hashtags #osm, #openstreetmap and #hotosm every three hours.
• rtnf asked why the OpenStreetMap Stats Generator needs an OpenStreetMap login and proposed a lightweight version without the need for credentials.

Programming

• [1] rtnf, inspired by posts on imagery collected by MapComplete (we reported earlier), has created a web app that randomly samples MapComplete images. In his blog, he explained how to visualise tagged imgur images on OSM.
• Jake Coppinger reported on his efforts writing a vector tile server for osm2streets to provide lane-accurate street maps with OpenStreetMap. Jake also revealed that his Safe Cycling Map now works for the entire world.
• Tobin Bradley recorded a screencast video that captures how protomaps is used to create a PMTiles file, a single file vector tiles format, and integrate it into a MapLibre demo map. This setup allows you to create vector tile maps with static infrastructure.
• starsep explained how Bing StreetSide imagery can be used for mapping with JOSM.

Did you know …

• … about the shop suffix for repair? You can use this to specify services available for computers, bicycles, shoes and more, as tooted by OSM Tourism.
• … Thomas Gratier’s comprehensive listing of map-related things?
• … the OSM Welcome tool, hosted by OSM-Belgium? This app helps identify new contributors to OSM in a given area, how many edits they’ve made, and their preferred editor. It also keeps track of which users have been sent a welcome message via the site.
• … the comparative overview of possibly every OSM-related Android app?

Other “geo” things

• The Equal Earth physical map of the world is now available in German, thanks to the work of Simon Scherrer.
• Devin Lea has started a new weekly social media hashtag #MapPromptMonday with a different theme each week. Last week the theme was using colour-blind friendly symbology. Upcoming themes have been listed.

Upcoming Events

Where	What	Online	When	Country
IJmuiden	OSM Nederland bijeenkomst (online)	✓	2023-01-28
南区	京都！街歩き！マッピングパーティ：第35回 六孫王神社		2023-01-29
Windsor	OSM Windsor-Essex Monthly Meetup		2023-01-31
San Jose	South Bay Map Night	✓	2023-02-01
Hannover	OSM-Stammtisch Hannover		2023-02-06
	MapRoulette Monthly Community Meeting		2023-02-07
	OSMF Engineering Working Group meeting		2023-02-07
Strasbourg	Mapathon CartONG		2023-02-07
City of Westminster	Missing Maps London Mapathon		2023-02-07
Stuttgart	Stuttgarter Stammtisch		2023-02-07
Zürich	OSM-Stammtisch		2023-02-08
Salt Lake City	OSM Utah Monthly Map Night		2023-02-09
London	London social pub meet-up		2023-02-08
München	Münchner OSM-Treffen		2023-02-08
Neufchâteau	OpenStreetMap – Réunion à Neufchâteau		2023-02-09
左京区	京都！街歩き！マッピングパーティ：第36回 金地院		2023-02-12
København	OSMmapperCPH		2023-02-12
San Jose	South Bay Map Night	✓	2023-02-15
Karlsruhe	Stammtisch Karlsruhe		2023-02-15
Olomouc	únorový olomoucký mapathon		2023-02-16

Note:
If you like to see your event here, please put it into the OSM calendar. Only data which is there, will appear in weeklyOSM.

This weeklyOSM was produced by ChristopherGS, Kasey2, MatthiasMatthias, Nordpfeil, PierZen, SK53, SeverinGeo, Strubbl, TheSwavu, barefootstache, derFred.
We welcome link suggestions for the next issue via this form and look forward to your contributions.

O cruceiro máis antigo de Louredo en pé. Sería o modelo no que se fixaron canteiros do pobo, como o señor Xaquín ou Juan Míguez, para tallar os outros dous?

Cruceiro e detalle do pé

O seu autor foi don Juan Míguez Domínguez. Este cruceiro, como o do Tabolado e o da Alfarrapa, segue un mesmo estilo sinxelo, de fuste octogonal e sen imaxes.

O único con inscricións, ilexibles inscripcións na súa base. Este pé de cruceiro ten varias (queda pendente revisar por cantas caras, pero alomenos son dúas (ollada onde se percorre o pé do cruceiro dende o frontal, pasando ó lateral esquerdo, traseira e lateral dereito: https://bit.ly/3Che3rK). Esta vese se te pos fronte a el e te agachas polo lado esquerdo. O solpor axuda a detectar os riscos, inda que eu non me atrevo a dicir que poñen. Xeralmente, data de confeción e donante.

Este cruceiro moveuse hai bastantes anos. Orixinalmente, ocupaba un recuncho, en curva, onda a casa “da raiana”, pretiño da casa do “grilo”.

O barrio da Torre queda en ladeira, limitando cos lugares dos Diestros e O Regueiro, na parte alta, co Cazapedo, por un lado, e O Outeiriño, polo outro.

Diante deste cruceiro pasa a procesión da festa do san Xoán, a da natividade do bautista. Pretiño del soe pararse a imaxe para a primeira oración (a segunda é na praza do Cazapedo) e a partir del enfílase cara o Cazapedo, comenzando a veces a tocar a banda que ameniza o paso.

Actualmente, o cruceiro de Louredo máis antigo que segue en pé (o máis antigo sería o que se conserva en parte, esnaquizado, no muro da viña do Pireiro, o único con imaxinería).

Clica para máis información

Situados na beira dun muro dunha viña, no lugar do Pireiro, estes anacos dun vello cruceiro son o testemuño máis antigo dun cruceiro en Louredo. Este situábase na Alfarrapa, preto da Telleira, e é un modelo único no pobo. Dispuña das imaxes do Crucificado, no alto, por riba dunha caveira, ós pés da cruz, onde estaban dúas imaxes máis: san Xoán e a Virxe. Digo que é único porque os cruceiros que viñeron despois son todos moi parecidos entre eles, sen imaxe algunha. Se o da Torre resulta ser o máis antigo en pé, podería ser o modelo que se seguí para os da Alfarrapa e Tabolado, ambos da autoría de don Juan Míguez Domínguez.

Este vello cruceiro caeu por mor dun carro que chocou con el, segundo unha versión, ou foi derribado por algúns republicanos en datas cercanas ó alzamento nacional, segundo outras fontes orais. O párroco, don Esteban, decidíu por os restos no muro da súa viña, ben visibles, e restauralo. Nunca pasou tal. Levantouse un novo cruceiro. Os restos están ben visibles no muro da antiga viña de don Esteban, enfronte dun cruce de camiños, así que poden visitarse e fotografar con toda facilidade.

Máis en:

1. Notas sobre os cruceiros de Louredo
2. Notas sobre restos do cruceiro no Pireiro

In case you wanted to use my note viewer with another openstreetmap-website-based project - now you can. Although most likely you didn’t because there aren’t many of them and they don’t use notes actively. Additional projects that note-viewer is already configured to work with are:

• OpenHistoricalMap (note-viewer link) - without map tiles unfortunately, because they don’t have raster tiles
• OpenGeofiction (note-viewer link)

It’s not a surprise that notes aren’t heavily used in these projects. Often you place a note where the map diverges from reality and you can’t edit the map at the moment. But neither OpenHistoricalMap nor OpenGeofiction represent something that is currently real. Right now OpenGeofiction has less than 100 notes, and it’s not obvious if that project even needs notes. Maybe they might use notes to coordinate editing of their collaborative territories?

Now you can also edit the loaded and selected notes by commenting, closing or reopening them. This might be useful to deal with several notes at once. Actually it was one of the original plans for note-viewer. The situations where it’s helpful include someone modifying a lot of notes without a good reason. For example, users sometimes close existing notes without making any map modifications or providing reasons why the notes are irrelevant. They may do this because open notes look wrong (red with x marks) and closed notes look right (green with ticks). Closing a note may look like confirming it. Probably that’s why users sometimes close even their own notes without making any edits. Now it’s possible to quickly deal with such note modifications by searching for a given username, followed by filtering for user’s close actions, selecting all filtered notes and reopening them.

Editing the notes most likely requires you to log in first. This is true for OpenStreetMap but I haven’t checked other servers. To log in or change a server, currently you have to open the About tab. Later I’ll replace it with a menu button. You can also configure note-viewer to use your own osm server there.

I’ve started a new project working with watmildon. While we were working together on applying the USGS Sq___ name changes to OSM we noticed was that there were often features in OSM that were out of sync with official name changes that happened years ago.

That got us thinking about walking through the USGS GNIS data set to find places where names had changed and OSM could be updated. After all, there are many features in OSM that have gnis:feature_id (and similar) tags that can be directly matched back to the GNIS data set.

After kicking the idea around for a while, we recently started writing some code. I’ve been working on a matching engine in C# that matches records from GNIS to OSM by Feature ID. The code also looks for likely matches where the feature name, primary tags, and geometry are close to the information from GNIS. So far the results are pretty good, but we’re still working on improving the matching.

Meanwhile, watmildon did some large scale statistical analysis on a local PBF file to look at the scale and scope of the problem. The results were very interesting!

Of the 2.3 million features in GNIS, there are only 1 million corresponding features with GNIS IDs in OSM. Some portion of these are surely existing features that just don’t have the gnis:feature_id (or similar) tags. But given our manual review of results from the matching code, there are a lot of GNIS features that are not present in OSM at all.

That’s not too much of a surprise. Some of the most common types of missing features are Streams, Valleys, Lakes, Springs, and Ridges – all things that not widely mapped in the US.

GNIS recently archived the feature classes for civil names and man-made features. About half of the 1.3 million GNIS records that don’t have corresponding features in OSM are for those archived features. You might reasonably wonder whether it’s worth tagging the archived features in OSM. But that leaves about 600,000 current GNIS features that aren’t fully tagged in OSM. And a large portion of those are likely not mapped at all.

At this point, we’re still working on improving our tools, collecting, and analyzing the data. There do seem to be some opportunities for some automated tag cleanup, and if that makes sense we’ll follow community practices for anything like that.

But fixing the untagged/missing features is going to require manual review and there are too many features for us do that alone. We’ll have to keep working to find ways to enlist the rest of the community to help!

Can someone explain why this happened? It seems there is some weird fisheye lens thing going on here.

https://www.openstreetmap.org/edit#map=19/42.71511/-108.98850

We are happy to announce the new release 1.8.0 of osm2pgsql.

The largest change is the addition of much more flexible index support in the flex output. The table definitions have a new (optional) field called indexes now which takes a list of index definitions. If the field is not there, we fall back to what we did before and create a GIST index on the only/first geometry column of a table. But you can also define any kind of index you want: define which index method (BTREE, GIST, …) to use on which columns, define WHERE clauses and expression indexes and much more. See the flex-config/indexes.lua Lua config for some usage examples and the manual for all the details. You can also force osm2pgsql to always build the id indexes which are normally only built in slim mode.

The gazetteer output and the command line option --with-forward-dependencies are deprecated in this release and will be removed soon. They were only needed for Nominatim which switched to using the flex output recently.

Here are the other changes:

• Fix a problem when using osm2pgsql with a projection other than WGS84 (EPSG:4326) or Web Mercator (EPSG:3857) which made the program really slow.
• New pole_of_inaccessibility() Lua function to generate reasonably good label points from polygons. (This function is currently marked as experimental, which means it can change without notice at any time.)
• Performance improvement for very small updates. Don’t spin up multiple threads when there are less then 100 objects to process, because the extra overhead is not worth it.
• Implement and use our own JSON writer. This removes the dependency on RapidJSON which hasn’t seen a new release since 2016.
• Add more checks (or does some checks earlier) to make sure your database uses UTF-8 encoding and that necessary database extensions are loaded and index methods, schemas and tablespaces you refer to in the config are actually available.
• A lot of code needed to be updated so it works correctly with any of the recent versions of the fmt library.

As always there were lots of code cleanups across the board, but especially in code accessing the database and in the C++/Lua glue code to make it more flexible and easier to use internally.

تاسیس 1400/11/03 سهامی خاص سرمایه اولیه ** تجربه کاری 1.اصلاح هندسی میدان مادر 2اصلاح هندسی میدان نگین 3ایجاد گذر گاه عابر پیاده 4 فرهنگ سازی ترافیک بر مبحث شهر ساری نوین 5…..