This article explains some changes:
[http://dev.maxmind.com/geoip/geoip2/whats-new-in-geoip2/]

Thanks for the suggestion!

Note: I read this on their site: Downloadable databases for GeoIP2 are not yet available. However, when they are, they will use our new MaxMind DB format. Once the databases are released, we will provide additional details on their use on this dev site.

SO we have to wait that they make the DB available.

yes I read this too but if you uses the links in the ticket above, you can already download the files...

+1.. there is a huge difference between geolite and geolite2 in terms of brute data..i downloaded both in csv and the newer one is 3x larger so 3x times more data! csv format is the accurate measure for comparison here, not compressed binaries which might work on different algorithms

hope to see this ticket solved.. in my case visitors` cities are correctly reported in less than 50 % of the cases (i use google analytics real-time map to compare, which is always accurate).. but i am sure that this is different from country to country, others might have 90% accurate results on the same old database

Trying to use the now legacy geoip database I get "Constant GEOIP_NETSPEED_EDITION_REV1 already defined", after inserting an if statement for checking if it was already defined GeoIP (PECL) is not able to tell me the database type. The message I get is: "This GeoIP implementation has access to the following types of databases: ."

Any chance this is going to get some attention soon so we can easily use geoip2 with piwik and not even worry about the above issue?

I am also getting the "Constant GEOIP_NETSPEED_EDITION_REV1 already defined" error. Is there a fix for this?

Downloadable databases for GeoIP2 are available now:
http://dev.maxmind.com/geoip/geoip2/geolite2/

So can we have Piwik support new GeoIP2?

I too get the "Constant GEOIP_NETSPEED_EDITION_REV1 already defined" Error. :(

The GeoIp2 database output is different from GeoIp1 concerning names, codes and structure.
See output gist using default test IP 194.57.91.215

As you can see, it also contains (some) translations of geographic names and the contenent_code for Europe has changed from "eur" to "EU".

Below are some questions to ask ourselves, but first some examples:

The city name output is:

[city] => Array
    (
        [geoname_id] => 3033123
        [names] => Array
            (
                [de] => Besançon
                [en] => Besançon
                // etc.
                [zh-CN] => 贝桑松
            )
    )

The Region Names aren't supported the way they are in GeoIp1. There now is an subdivisions property containing an array of area's. For above IP that's as follows; index 0 being the "biggest":

[subdivisions] => Array
    (
        [0] => Array
            (
                [geoname_id] => 3017372
                [iso_code] => I
                [names] => Array
                    (
                        [de] => Franche-Comté
                        // etc.
                        [fr] => Région Franche-Comté
                        // etc.
                    )
            )

        [1] => Array
            (
                [geoname_id] => 3020989
                [iso_code] => 25
                [names] => Array
                    (
                        [de] => Doubs
                        // etc.
                    )
            )
    )

For different countries, the devisions are different and not necessarily mapping to the GeoIp1 setup.

What is the best way to handle these changes?
I don't know. Some questions that I think should be answered first:

Converting the new GeoIp2 output to exisiting GeoIp1 data will be error prone, so maybe it's best to store visit-data in a new format (using the geoname_id's only)?

Should current visit-data be transformed into the GeoIp2 structure?
If not, how to mix both GeoIp1 and GeoIp2 data in reports?

In #6690 (comment) @olavmrk suggested making a split between new installs and existing setups. Is that feasible?

Implement server support for apache and/or nginx ?

I'm looking forward to your comments...

Hi @joostdekeijzer

it's nice to talk about this important new feature :-)
Here are some notes:

Implementation: I think Geoip2 support in Piwik should be implemented as a location provider just like GeoIP is currently implemented. (code). The implementation detail of the geoip2 location provider will be hidden in the location provider class, via the implementation of these few methods here: https://github.com/piwik/piwik/blob/master/plugins/UserCountry/LocationProvider.php#L67-135

Admin UI: currently users can choose in the Geo location UI to use Default or GeoIP (Php) or GeoIP (Pecl) or Geoip (Apache).
With Geoip2 support they could also choose for example the new Geoip 2 (Php) and maybe Geoip2 (PecL) and Geoip2 (apache) (not sure what options there are for geoip2)

Data migration: I think we don't have to worry about data migration for this task, as IMO there won't be major issue there (but maybe i'm missing something).

I hope it helps, let me know if you have any other question!

Hello,
what is the status of the implementation of Geoip2?
Can we download and you use it?

Thanks.

From my usage I haven't noticed issues anymore.

@g-p-g are you sure you are using the enhanced database of geoip version 2 ?
version 1 is working fine of course...

@hpvd I posted here about 1 year ago regarding this issue (you can see my comment way above). It's working for me using the latest Piwik release (not just the latest, but a few before the latest too). It's also possible that Piwik upgrades stopped reverting changes in place to get this working, which until a few version ago had to be redone after each update.

@g-p-g How did you make it work.
Previous files were .dar files and these new ones are .mmdb.
Did you made some modifications?

@AgentGod, @hpvd, and others sorry for the false hope. I mixed this with other things, the Piwik installation is in fact not using geoip2.

not good news @g-p-g :)
@mattab is there any ETA for implementing the option you describe in your post?

No ETA yet, we have not scheduled this improvement at this stage. It would be awesome if a developer from the community would issue a Pull request for this, but I understand it is a non trivial change.

Hi all,

I have done some work on GeoIP2 support, but currently don't have time to continue on it. I can PR it, but it's not finished.

See:
https://github.com/joostdekeijzer/piwik/tree/GeoIP2 or more specifically https://github.com/joostdekeijzer/piwik/commit/258f7a7584af7f3c9d42bb9cc9569334fb151ed7 which is the commit to add my current implementation.

Don't forget to run compuser update to install the GeoIp2 code.

Good to know
The new GeoIp2 libraries don't support the area_code, so it's left empty.

What it does do

• Read mmdb files if properly named and put in the /misc/ directory
• Output GeoIP info, but I've only tested by calling the API, eg: /index.php?module=API&method=UserCountry.getLocationFromIP&ip=194.57.91.215&format=JSON what looks fine

Needs work on

• tests (currently none)
  • some IPv6 addresses to test with that are "future proof" and "non IPv6-mapped IPv4"
  • Since the mmdb format is open, maybe create a small custom test mmdb with a static set of data?
• auto-update datafiles
  • The current automatic updates forms are hard-coded and only for the .dat files. It should change depending on which location provider is selected?
  • The auto-update cron function must be updated to download and test mmdb files
• speed
  • Needs testing
  • Not sure if https://github.com/joostdekeijzer/piwik/commit/258f7a7584af7f3c9d42bb9cc9569334fb151ed7#diff-663e1f37bf83d5b3c62915f859c498a7R47 is the best solution since the city and country datafiles overlap and if city is available probably country shouldn't be used.
• probably a lot more! ;-)

+1 for this - would love to pay for a more accurate database to use with Piwik :)

wow. Many thanks for these that fast and positive pieces of information!

regarding testing autofetch: the 2 free databases available also got updates from time to time (and needs to be refreshed) :
https://dev.maxmind.com/geoip/geoip2/geolite2/

The performance characteristics of the new version may need to be tested against the legacy database. In the Java version of the GeoIP2 plugin there is a performance issue related to text deserialization.

Obviously Piwik is not Java, but it'd be unfortunate to see a significant regression in lookup times, especially if Piwik doesn't use most of the new data.

@diabl0 your plugin is not working for me in piwik 3.0. See #11034

In our case we need accurate Maxmind and Intranet IPAM information.
As i donot see how to chain location providers currently with
i cloned diabl0s work and added a Intranet Data loookup in front of the maxmind dbs.
So if found in the own IPAM data it takes this data. If not use Maxminf
diabl0/piwik-geoip2#4
https://github.com/grzchr15/piwik-geoip2-andintra

Tested with Piwik 3.0.0

I am using it with latest Piwik 3.0 and seems working fine

Has anyone had any luck getting the ISP and sort data to show in Piwik? We have not yet been able to install the ISP/Org database, we have access to the new version (2) and the legacy version. We've put both types of files into the misc directory but we are still seeing "Org: Unknown ISP: Unknown".

We have been able to install the lite city database.

We need to bundle support for Geoip2 in Matomo very soon, ideally before April 2018, as it will stop getting updates then.

On the official page for GeoLite Legacy it says:

We will be discontinuing updates to the GeoLite Legacy databases as of April 1, 2018. You will still be able to download the April 2018 release until January 2, 2019. GeoLite Legacy users will need to update their integrations in order to switch to the free GeoLite2 or commercial GeoIP databases by April 2018.
For more information, please visit our Support Center. https://support.maxmind.com/geolite-legacy-discontinuation-notice/

In addition, in 2019, latitude and longitude coordinates in the GeoLite2 databases will be removed.* Latitude and longitude coordinates will continue to be provided in GeoIP2 databases. Please check back for updates.

(this was noted in a separate issue #12411 )

Proposed steps

• Re-use the GeoIP2 plugin from the Marketplace and move it into core in our UserCountry plugin.
  • ensure we have automated tests
  • update the little wizard to setup geo-location so it automatically sets up the download of the Geoip2 databases instead of legacy format.
  • add new system check to issue a warning when the "old" geolocation is used to invite users to setup GeoIP2 and still get updates
• Test that commercial city database, and also ISP, organizations databases, still work and populate the data
• Test that IPv6 geo-location work. This is a big problem with the current Maxmind, that geolocation on ipv6 often return "China" instead of correct country. IPv6 Geolocation is not working #8601
• Update our user guide: https://piwik.org/docs/geo-locate/
• Update all FAQs still linking to the legacy formats and referencing GeoIP v1, and also update instructions on how to use the commercial database

maybe this helps some how:
https://github.com/maxmind/GeoIP2-php/releases

Would love to the see the geoip2 support. I have it in my server logs, but not in my matomo yet

Also love to see Matomo gets an compatibility update since the very soon upcoming deprecation 👍

Matomo 3.5.0-RC includes Geoip2 as a separate plugin 🎉 🚀

Testing welcome. please enable the GeoIp2 plugin, then go to Administration > Geolocation > and select the new Geoip2 driver. Feedback welcome!

I have upgraded and had the old GeoIP2-Plugin (available at the marketplace) enabled. Note that upgrading breaks the system if the old plugin is still installed. Uninstall before the upgrade. If you forgot (or didn't know), a blank page (internal PHP error) will replace the usual UI.
To get rid of the blank page:
Delete the /plugins/GeoIP2 folder (note the big P in the filename). The Matomo UI should now load normally. Don't forget to completely uninstall the old plugin in the plugin manager in the Matomo Administration.

Just performed the upgrade and stumbled upon the same issue. Would be great, for the next users who are going to upgrade, if there was a red warning about this before the upgrade, because without the above GitHub comment by @Lozik it would have taken me some time to discover it and there would have been a long service interruption.